Build Master: Scheduling

[Sönke Ludwig]

Am 14.11.2013 06:05, schrieb Tyro[17]:
> On 11/13/13, 11:30 PM, Andrej Mitrovic wrote:
>> On 11/14/13, Brad Anderson <eco at gnuk.net> wrote:
>>> 6 months between releases means a regression that was introduced
>>> in the latest version requires you to wait another 6 months for
>>> the fix which means you are running a version that is a year out
>>> of date.
>>
>> 6 months is ridiculously long. The changelog itself will have to span
>> pages. And because a lot of people do not use DMD-head we'll end up
>> with a ton of regressions that are only caught after a release is
>> made. And people who want an important fix will have to wait 6 months
>> for a release. New library features or modules will only be properly
>> tested after a release, so that means potentially waiting 6 months
>> with very little feedback.
>>
>> IMO 6 months is unacceptably long. We're not steering an oil rig here,
>> D is supposed to be a speedboat.
>>
> 
> It's been approximately six months since the release of 2.063 (alright
> five+: May 28 to Nov 5). I don't think too many of us lost sleep over
> that. There is nothing ridiculously long about six months.
> 

Just a little personal impression - it seems like during 2.064's
development, more people than ever have switched to DMD HEAD instead of
the last release version. This made it much more burdensome to support
public libraries, because compiler induced breakage was much more frequent.

So considering the *current* way releases are done, I'd be very much in
favor of a shorter release schedule, maybe 3 months (remember that there
were times where the cycle was about 1 month), so that there is less
pressure to go GIT HEAD.

However, regular point releases and betas would arguably achieve this,
too, so if the proposed plan is actually really followed like that, I'm
all for it.