On 24/07/12 19:27, Adam Wilson wrote:
On Tue, 24 Jul 2012 01:50:02 -0700, Don Clugston <d...@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.
