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.

Reply via email to