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