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.
