Preparing for a point release

Eric S. Raymond esr at
Wed Dec 6 19:54:41 UTC 2017

Matthew Selsky via devel <devel at>:
> OK, then let's put those several fixes on a branch from the 1.0 tag and release from there (if we're looking for a quick release).
> There's been too much churn in non-PLL code removal, waf changes for
> python install paths, etc, to mix chose changes with actual
> user-impacting bugs (for users that were OK with the previous
> implementations of the python paths).
> If we do a slow release, then, sure, just release 1.1 with everything.

Then I'm going to say that I think all releases should be "slow" in
this sense.

Remember, Linux used to have stable-branch releases.  It no longer does
because Linus noticed the same failure mode I did.  When you start
cherry-picking onto a "safe" branch you increase the expected time to
discovery of any bugs on your unstable branch.  This is not a good trade
in the longer term.
		<a href="">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute:
Please visit their site and donate: the civilization you save might be your own.

More information about the devel mailing list