Build Master: Scheduling

[Martin Nowak]

On Friday, 15 November 2013 at 09:17:45 UTC, ponce wrote:
> Do you happen to work with me? We have two dozens of such 
> releases branch :) And customers still tend to prefer the 
> slightly bleeding edge ones.
>
> While this effectively _does_ work in creating more stable 
> releases, I think that it puts all the burden on the developers 
> in a way that is difficult to ignore.
>
> Most of the time backporting is little work, but sometimes you 
> need to redo a fix you already did, for a branch which only 
> exist to be phased out a bit later, in a codebase slightly 
> different in ways nobody can tell anymore. Sometimes it's even 
> very hard to backport a fix, but if you don't do it how to tell 
> which branch has which bugs?
>
> Coupled with being forced to backport every bugfix to every 
> branch, this can make a compelling enough reason never to 
> contribute.
>
> With a typical bad fix injection rate of ~5%, this also mean 
> regressions will crop up in release branches and never be 
> noticed since they are not introduced at HEAD level but by the 
> very act of backporting.
>
> I'm not sure it can be done in a way that feels right. I prefer 
> the N-month release cycle we have, and take as much time and 
> Release Candidates as needed.

That's the exact problem with most of the release ideas proposed 
here, they are terribly inefficient.
The schedule proposed by Andrew only requires one maintenance 
branch (point releases) besides the regular beta releases from 
master. Backporting to a single stable branch should be within 
our budget.