Build Master: Scheduling

[Xinok]

On Thursday, 14 November 2013 at 00:37:38 UTC, Tyro[17] wrote:
> Greetings,
>
> I have accepted the responsibility of preparing the builds for 
> DMD and would like to engage in conversation about the way 
> ahead.
>
> The first concern I have is about the build cycle. Presently, 
> it is nonexistent. There is no rhyme or reason regarding when 
> releases are produced. The v2.065 agenda (first attempt of its 
> kind) suggests that the next release will occur sometime in 
> March 2014. I'm of the opinion, however, that the cycle should 
> be six months long. This particular schedule is not of my own 
> crafting but I believe it to be sound and worthy of emulation:
>
> ...
>
> Your thoughts and concerns please.

I think this is perfect. It's essentially what I would do. Ever 
since Google defined their six week release schedule for Chrome, 
people think quick release cycles are the next great thing. It 
was such an effective marketing strategy that Firefox had to jump 
the bandwagon. The truth is though, it doesn't cater well to 
large corporations. That's why Firefox also has ESR (Extended 
Support Release) for corporations which are older versions 
maintained for longer, only being updated for new bug and 
security fixes.

I think the majority of people active on these forums are 
hardcore D enthusiasts so they're eager to have the latest and 
greatest. However, we're not hearing the voice of those on the 
outside. I'm willing to bet if we were to post this as news on 
Reddit, we'd be getting praise from those who aren't actively 
involved in the development of D.


I do have a few ideas:

I'm one who favors having different version numbers for beta and 
stable releases. Given the version number scheme that DMD 
follows, a simple numbering scheme to follow is odd- and 
even-numbered versions: odd-numbered versions, starting with 
2.065, would be beta, and even-numbered versions, like 2.066, 
would be stable.

I would define two periods during the release cycle: Early on, 
when it's okay to introduce new features and changes which may 
break code, and later on when we should be concentrating on 
testing, fixing bugs, and generally working towards a stable 
release.

Finally, I think after every stable release, we should define an 
agenda, i.e. what are our goals for the next version? My current 
impression is that pull requests are incorporated into master 
whenever they're deemed ready. If we have a clear agenda, then we 
could collectively focus our efforts into a few areas for 
development.