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.

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/

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/

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

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.

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'.

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."

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.

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

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/