Re: Freezing for 2.18

[David Kastrup]

Janek Warchoł <address@hidden> writes:

> On Mon, Mar 11, 2013 at 3:53 PM, David Kastrup <address@hidden> wrote:
>> Uh Janek?  We have _never_ made a branch for stable releases until
>> after we reached a state of convergence.  The problem is that in
>> order to get a stable release from a wobbly starting base, we need
>> testers.  If all developers move on to the unstable branch and the
>> unstable branch gets extensive work, testing of the fixes required to
>> get a release ready will fall apart.
>
> ok, i see your point.
>
>> After cutting the stable release branch, what goes in there are
>> documentation fixes, well-exposed cherrypicks of bug fixes, and
>> reverts of regressions.  Basically stuff that is _certain_ to improve
>> release quality, judging from the beating it has seen in master
>> because, like it or not, that's what people are working with and
>> looking at.  If the unstable branch gets _extensive_ changes, this
>> approach falls down.
>
> Here's where my reasoning was flawed - i thought that even if the
> unstable branch will get extensive changes, it will be possible to
> cherry-pick stable stuff into stable branch.

Large projects with a lot of developers work with that sort of strategy.
The problem is that we are a large project with a small number of
developers.  I'm not optimistic about the prospects of this working
well.  If we have large changes in the backend in the unstable branch,
the results of subsequent backend fixes are not representative for what
cherry-picking them into the stable branch would achieve.

So for the stabilizing period after branching off a stable release
candidate, we can't afford invasive changes even to the unstable branch
until after completing the stable release.  That does not mean that the
unstable branch has to stop development as well: it just means that the
changes to the unstable branch should be well-confined so that testing
changes remains relevant for the stable branch, and so that
cherry-picking fixes is likely to work well when the fixes have tested
well in the unstable branch.

> Hm.
>
> thanks for correcting me.

Well, that kind of stuff is not set in stone.  It's just what worked
reasonably well for LilyPond in the past.

-- 
David Kastrup