Adopting the Linux/Firefox/Chrome release strategy

[Friedrich W. H. Kossebau]

Am Mittwoch, 13. Juli 2016, 14:30:15 CEST schrieb Boudewijn Rempt:
> What I want to propose is following other fast moving projects like
> Linux kernel, Chrome or Firefox and have:
> 
> * All feature development done in dedicated feature branches. These
> branches should be named like Nishant's branch: NAME/feature-description.
> 
> * A six week release schedule with:
> 
> ** a merge window of two weeks after each release: every feature that
> is ready can be merged in those two weeks. Outside those two weeks only
> bug fixes go into master.
> 
> ** A four week stabilization/translation window. This should be sufficient
> to allow the translators to keep up and to fix any stability issues that
> occur after a feature is merged.
> 
> * Numbering like this: 3.0.x until we have all features promised for
> the 2015 kickstarter, then 3.1.x, until we have all features promised
> for the 2016 kickstarter, then 3.2.x.
> 
> * A release procedure where we package the translations into the source
> tarball, as discussed before; I can then fix my build scripts to build
> from the source release instead of a git tag.

Sounds good to me as by-stander.

Just one thing I wonder: what about fix-up releases with little or big fixes 
to new features or regressions, which are only uncovered after the release, 
once the big user crowds have done the real world mass testing? Delaying those 
6 weeks as well, until the next release, might be working against an idea of 
getting things out quickly to the users.

Thus I propose to consider adding a small time-window after the big release, 
say 1 week, at the end of which there would be a fix-up release (perhaps only 
if needed), and only then open the merge window.

Cheers
Friedrich