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
