View mode: basic / threaded / horizontal-split · Log in · Help
July 15, 2012
Re: D versionning
On 7/12/2012 3:40 PM, Patrick Stewart wrote:
> Most ridiculous thing about D is that it breaks so much backward compatibility that people just give up using it. Decent versioning like this might help people stick to something.
>
> Wake up, guys, it is 10+ years and *still* it haven't reached some form of stable release.
>
> Like I sad, engineering failure.
>

We did do a stable release, D1, and there were plenty of complaints that D1 did 
not get new features.

Also, all the released versions of D are available for download. There is no 
need to constantly download the latest if that disrupts your projects.
July 15, 2012
Re: D versionning
On Sun, 15 Jul 2012 14:36:06 -0700, SomeDude <lovelydear@mailmetrash.com>  
wrote:

> On Sunday, 15 July 2012 at 20:50:47 UTC, Patrick Stewart wrote:
>>> OTOH, it may break the community yet again, which we certainly don't  
>>> want, probably even less than breaking code.
>>> Also, the example of Python with two main stable branches that live in  
>>> parallel is not very encouraging.
>>
>> Also, check Python website: they recommend python v2 for all new users  
>> that don't know what to choose. They are both stable, but v2 has more  
>> libraries, and they do reassure them by saying v2 will be supported for  
>> time to come.
>>
>> On the other hand, on D website, D1 is pushed to the dark corners as  
>> ugly half child nobody should know about, and D2 is titled as thing to  
>> chose without thinking. And there is no mentioning D1 is relatively  
>> stable, while D2 is still unstable, non conforming to D documentation  
>> and that some things just don't work, while in constant beta flux that  
>> breaks things on regular basis with each release.
>>
>> So tell me again, which language treats its users with more respect ?  
>> Which one encourages users more to use them?
>
> The problem I raised is not a problem of respect. It's a problem of  
> community. The D community is a tiny fraction of the Python community.  
> It has been steadily growing this last year and a half or so, but it's  
> still fragile. The D1/D2 split basically set it back to near zero for  
> several years, with many people leaving, only a few staying, and a  
> number recently coming back.
>
> The project certainly can't afford yet another split, or many key people  
> will simply throw the towel. I for one would rather see part of the  
> users quitting than active members.
>
> As for the stability of D2, upir opinion may be different, but it has  
> largely improved recently due to increased forces, as several people  
> have noted (David Simcha in a recent thread said something about the  
> stability of the compiler being good enough that he only rarely  
> encountered a problem). And considering the rate of bugs correction, it  
> will continue to improve. You only need to have a look at the changelog  
> to see that it's growing with each release, and I'm pretty confident  
> that the 2.060 will contain more bug fixes than any past release.

You are concerned that adopting an OSS best-practice is going to split the  
community ... seriously? I find that a very hard argument to swallow with  
a straight face. We aren't splitting D2 into a D3, are simply arguing for  
a bugfix branch (stable) and a new feature branch (dev). How, pray tell,  
is this a split? We are merely seeking to make two things that are  
logically unrelated, bugs and new features, and make them physically  
unrelated as well.

The idea that bugs and new features can and should be rolled into the same  
release runs counter to every accepted best practice in both FOSS and  
Commercial wisdom. The two have VERY different velocities, bugs can be  
fixed in days, but new features take much longer. Consider COFF support  
for example, Walter has been hammering away at it for weeks now, and he  
isn't even 50% done, how many bugs have been fixed and confirmed resolved,  
in the same timespan? Also, consider that adding new features makes it  
significantly harder to track down regressions (is a real regression or  
did the new feature upset the code in an unexpected way) and the new  
features themselves create new bugs. If the branches are separate then it  
becomes trivial to determine if the new feature caused the bug, because it  
will show up in one and not the other.

How DARE we DEMAND that our users wait 4 MONTHS for regression fixes  
because we are afraid of a split or a little extra work? How many users  
could we lose if we significantly slowed down the release cycle (and  
therefore the bugfix cycle) such that people are waiting many months for  
their fixes? The language would be perceived as dead/dying and that would  
be just as bad as the D1/D2 split. If you allow your past experiences to  
paralyze you into inaction, you will bring about the very problem you seek  
to avoid.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
July 15, 2012
Re: D versionning
On Sun, 15 Jul 2012 14:58:14 -0700, Walter Bright  
<newshound2@digitalmars.com> wrote:

> On 7/12/2012 3:40 PM, Patrick Stewart wrote:
>> Most ridiculous thing about D is that it breaks so much backward  
>> compatibility that people just give up using it. Decent versioning like  
>> this might help people stick to something.
>>
>> Wake up, guys, it is 10+ years and *still* it haven't reached some form  
>> of stable release.
>>
>> Like I sad, engineering failure.
>>
>
> We did do a stable release, D1, and there were plenty of complaints that  
> D1 did not get new features.
>
> Also, all the released versions of D are available for download. There  
> is no need to constantly download the latest if that disrupts your  
> projects.
>

And with the comming deprecation of D1, what then?

Going backwards is almost never the answer with D2, the bugs are almost  
always still there.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
July 15, 2012
Re: D versionning
On Sunday, July 15, 2012 14:58:14 Walter Bright wrote:
> On 7/12/2012 3:40 PM, Patrick Stewart wrote:
> > Most ridiculous thing about D is that it breaks so much backward
> > compatibility that people just give up using it. Decent versioning like
> > this might help people stick to something.
> > 
> > Wake up, guys, it is 10+ years and *still* it haven't reached some form of
> > stable release.
> > 
> > Like I sad, engineering failure.
> 
> We did do a stable release, D1, and there were plenty of complaints that D1
> did not get new features.

Well, if we were to move to a model where we had 2.x.y, we only put new 
features on changes to x, and bug fixes when in changes to y, and we did x 
releases every few months and y releases monthly (or something along those 
lines), then people would theoretically get a more stable release to work off 
of with the new features still coming semi-frequently. You get a better 
balance between stability and new stuff than we've had. And I think that in the 
long run, that's probably what we should do. Instead, what we've had is either 
stability without any new features or at all or a new features but a lack of 
stabliity.

The problem is that we're still ironing out too much, and most of the breakage 
relates to bug fixes, not new features. I think that we need to reach the point 
where D is more or less at where TDPL says it should be before we go to a 
model we're splitting out the new stuff from the bug fixes. In theory, the only 
new stuff that we're doing right now relates to matching TDPL and ironing out 
issues with existing stuff rather than outright adding new features anyway 
(though some outright new stuff _has_ been added - e.g. the new lambda syntax). 
So, in that sense, pretty much everything is supposed to be bug fixing right 
now.

- Jonathan M Davis
July 15, 2012
Re: D versionning
On 7/15/2012 3:27 PM, Jonathan M Davis wrote:
> The problem is that we're still ironing out too much, and most of the breakage
> relates to bug fixes, not new features.

There's been a lot of non-bug-fixing breakage, for example, renaming library 
functions.
July 15, 2012
Re: D versionning
On 7/15/2012 3:00 PM, Adam Wilson wrote:
>> Also, all the released versions of D are available for download. There is no
>> need to constantly download the latest if that disrupts your projects.
>>
>
> And with the comming deprecation of D1, what then?

It'll still be there for download for those that want to use it.


> Going backwards is almost never the answer with D2, the bugs are almost always
> still there.

To me, 'stable' means unchanging, not 'has no bugs'.
July 15, 2012
Re: D versionning
On 7/14/2012 6:42 PM, Adam Wilson wrote:
> I believe that there IS a problem here. There are people who, for various
> reasons, cannot use Git HEAD, and they have open problems. They are stuck. I
> believe that is the unstated impetus for this thread.

There is no answer to:

"Do not change things, but change everything."
July 15, 2012
Re: D versionning
On 7/15/2012 10:25 AM, captaindet wrote:
> pls make a fresh build available on a weekly or at least biweekly basis, just
> with regressions fixed.

2.059 had only 3 outstanding regressions.
July 15, 2012
Re: D versionning
On Sunday, July 15, 2012 15:30:57 Walter Bright wrote:
> On 7/15/2012 3:27 PM, Jonathan M Davis wrote:
> > The problem is that we're still ironing out too much, and most of the
> > breakage relates to bug fixes, not new features.
> 
> There's been a lot of non-bug-fixing breakage, for example, renaming library
> functions.

Yeah, but those are always done through a deprecation path, so there's no 
immediate breakage. And we've done most of that already, so that should be 
happening less and less.

However, if we did move to a model where we had major and minor releases, then 
deprecating and removing functions would presumably be restricted to major 
releases.

- Jonathan M Davis
July 15, 2012
Re: D versionning
On Sun, 15 Jul 2012 15:32:06 -0700, Walter Bright  
<newshound2@digitalmars.com> wrote:

> On 7/15/2012 3:00 PM, Adam Wilson wrote:
>>> Also, all the released versions of D are available for download. There  
>>> is no
>>> need to constantly download the latest if that disrupts your projects.
>>>
>>
>> And with the comming deprecation of D1, what then?
>
> It'll still be there for download for those that want to use it.
>

I guess my point is that at that time we only have one operative branch  
per your implication. Great, it's still there, but it's un

>> Going backwards is almost never the answer with D2, the bugs are almost  
>> always
>> still there.
>
> To me, 'stable' means unchanging, not 'has no bugs'.
>

So the problem is semantics then? Because I dredge up another word to  
describe what we are asking for if that's all it takes. But I don't think  
that anyone else is going to read "stable" as "unchanging". Software is by  
definition changing, or it's dead. It appears to my parsing of your  
sentence that you are asserting that stable == static. By that definition  
of stable, Windows ME is "stable" and ... ehrm, not a soul in the tech  
world would agree with that summation of WinME.

As I said earlier, no one else in FOSS or Commercial equates stable with  
"has no bugs", it means no new features and no regressions. Not a single  
solitary person I've talked too expects their software to be bug free.

THIS is what we mean when we say "stable":  
http://www.modernperlbooks.com/mt/2009/06/what-does-stable-mean.html
It's also how pretty much everyone else will read "stable".

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
1 2 3 4 5 6 7 8 9
Top | Discussion index | About this forum | D home