Preparing for a point release

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


Matthew Selsky via devel <devel at ntpsec.org>:
> 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="http://www.catb.org/~esr/">Eric S. Raymond</a>

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




More information about the devel mailing list