Coming Soon: Stable D Releases!

Jacob Carlborg doob at me.com
Wed Jul 25 23:35:26 PDT 2012


> 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?

You can at least come to an official agreement that we should release on 
a given interval. Then we don't need to stop the world to make that 
happened. Sometimes it will be delayed and that would be acceptable. If 
we do have a release schedule and Walter, for example, knows he will be 
on vacation during the release week. We can plan ahead and annoyance 
that the next release will be delayed or skipped.

> 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?

No, no, no. That's another problem. Don't commit anything to 
upstream/master that isn't finished. I don't know why Walter does that. 
Does he not have his own fork? Why not create a new branch at least?

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

Agree.

-- 
/Jacob Carlborg


More information about the Digitalmars-d-announce mailing list