Coming Soon: Stable D Releases!

[Adam Wilson]

On Wed, 25 Jul 2012 00:43:23 -0700, Don Clugston <dac at nospam.com> wrote:

> On 24/07/12 19:27, Adam Wilson wrote:
>> On Tue, 24 Jul 2012 01:50:02 -0700, Don Clugston <dac at nospam.com> wrote:
>>
>>> On 16/07/12 09:51, Adam Wilson wrote:
>>>> As a result of the D Versioning thread, we have decided to create a  
>>>> new
>>>> organization on Github called dlang-stable. This organization will be
>>>> responsible for maintaining stable releases of DMD, DRuntime, and
>>>> Phobos.
>>>>
>>>> So what is a stable release?
>>>> A stable release is a complete build of DMD, DRuntime, and Phobos that
>>>> ONLY includes the latest bug-fixes and non-breaking enhancements to
>>>> existing features. It will not include, new features, breaking
>>>> enhancements, and any other code that the core development team may be
>>>> working on.
>>>
>>> I'm not actually sure what this means. I fear that it may be motivated
>>> by an inaccurate assessment of the current situation.
>>>
>>> The existing instability comes almost entirely from Phobos, not from
>>> the compiler. Historically there have been very few instances where
>>> you might want to choose an older compiler in preference to the latest
>>> release.
>>>
>>> As I've said before, the one time when a language change caused
>>> *massive* instability was in the attempt to move AAs from language to
>>> library -- even though that wasn't even supposed to affect existing
>>> code in any way. The other thing that typically causes regressions is
>>> fixes to forward-reference bugs.
>>>
>>> Historically, addition of new language features has NOT caused
>>> instability. What has been true is that features have been added to
>>> the compiler before they were really usable, but they have not broken
>>> existing code. Fairly obviously the 64 bit compiler was quite buggy
>>> when initially released. But even that massive change wasn't much more
>>> buggy than the library AAs! So I am not sure that you can correctly
>>> guess where instability will come from.
>>>
>>> In summary -- I would not expect your stable DMD to be very different
>>> from the normal DMD. Phobos is where the instability issue is.
>>
>> There are three issues we are trying to address:
>>
>> The first and largest issue is the long and variable periods between DMD
>> releases. By the end of the 2.060 Beta period there will have been at
>> least 3.5 months since 2.059. And while for the people who can use Git
>> HEAD this may not be a problem, there are MANY who, for whatever reason,
>> must use the released versions. For them the 314 resolved issues and
>> dozens of regressions fixed are a tantalizingly out of reach.
>
> I agree, but the fact that has happened, is just plain silly. There is  
> no sensible reason why this happened. We were in fact ready for a  
> release nearly two months ago. Somehow it did not happen. That  
> ridiculous situation is the thing that needs to be addressed, IMHO.
>
> In fact, I see no reason why we couldn't do a release every month.
>
>> The second issue is the root of the first. Much of the delay was caused
>> by Walter starting to work on COFF. Which brings up the second point of
>> contention in the community, a significant number of bugs are typically
>> introduced when this new work is introduced precisely because it's not
>> ready,
>
> I do not believe that at all. Where is the evidence for it?
>
>> The third is the result of the first two. The slow release cadence
>> combined with the requirement to push new features along side bug-fixes
>> is seriously holding back the growth of the D community. There is a
>> feeling out here that D is lurching unsteadily forward when it should be
>> smoothly accelerating and most of this feeling is rooted in the prior
>> two causes. This has a very corrosive effect on the community and
>> particularly their willingness to contribute.
>>
>> The goal of dlang-stable is to provide the primary development team
>> (you!) with the ability to release whenever you feel a new feature or
>> enhancement is stable enough to be released WITHOUT having to worry
>> about the ever growing number of bugfixes that are backlogged in with
>> the new features. We are trying to reduce the bugfix pressure so that
>> you can focus on delivering high-quality code when it's ready.
>>
>> The community WANTS these new features, but we CAN'T wait 3.5 months (or
>> more!) for the bugfixes that are baked in with them. We have to provide
>> BOTH.
>
> We don't need this complexity. The solution is *trivial*. We just need  
> to decide in advance that we will target a release every X weeks, and  
> that it should be delayed only for reasons of stability.
>
> An agreement is ALL that is required. But despite repeated requests, I  
> have never been able to get any traction on the idea.
> Instead, people propose all kinds of crazy technical solutions, the most  
> recent ones being changes to bugzilla, trello, and now dlang-stable.
>
> If we say, "There will be a new compiler release every 8 weeks", the  
> problem is solved. Seriously. That one-off agreement is ALL that is  
> required.
>
> But the D community finds it easier to implement a new 64-bit Windows  
> compiler, than to make a agreement on a short-term release schedule.  
> We're a strange bunch, I tell you.

I don't think a rigid release schedule has ever worked in software  
development. Linus is world-renowned for releasing at what looks like  
utterly random intervals and I know of very little software that ships on  
a strict time based cadence. It almost ALWAYS slips for some reason or the  
other.

I guess my point is that it isn't as easy as making the schedule the final  
arbiter because it is an attempt to deny that the real world exists. What  
if Walter is on vacation (I don't know if he believes in vacations but,  
bear with me) during release week? What then? Do we demand that he  
organize is life around our precious release schedule?

Also, what about projects that absolutely cannot be completed in under X  
weeks? Do we just leave the code in the release, half working, waiting to  
spread all KINDS of bugs?

That sounds to almost everyone here like a recipe for complete disaster.  
More to the point, I know of no successful project, OSS or Commercial,  
that follows this model. Development and Stable releases are a staple of  
the Open-Source world, and it would behoove us to learn from those who  
went before us. If the model doesn't work, why is it nearly universal? Do  
we really think that we are better than Linux or LibreOffice or Java?

I would make an argument that such thinking is one of the things holding D  
back. The industry is crying out for something like D ... just look at the  
proliferation of new native languages that attempt to address the problems  
of C/C++ in their own ways; and yet, D, with it's clean syntax and  
multi-paradigm capabilities is a bit player.

If I had my way, this would all be handled by the dev team via Git  
branching. But it appears that Walter was unwilling to do the work, so we  
the community have stepped up. It is an entirely predictable outcome of  
the very real pains felt in the community. And dlang-stable is essentially  
a branch of the HEAD repos, just with more process in between. Less  
efficient, certainly. Will it fail ... I doubt it, but let's find out.

And seriously, the flexibility to release whenever and not be pressured by  
the community at large because we've gone so long with bugfixes should be  
freeing to the dev team, not constricting!

As a side note, 64-bit support is critical to the long term viability of  
D. 32-bit is a rapidly dying concern, once ARM 64-bit goes mainstream the  
party is over. 32-bit will be archaic by the end of the decade, and out of  
common usage well before then.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/