Preparing for a point release
Matthew.Selsky at twosigma.com
Wed Dec 6 18:48:43 UTC 2017
On Wed, Dec 06, 2017 at 12:14:18PM -0500, Eric S. Raymond wrote:
> Matthew Selsky via devel <devel at ntpsec.org>:
> > On Tue, Dec 05, 2017 at 12:35:34PM -0800, Hal Murray via devel wrote:
> > >
> > > If you want to do a quick release, then we should backport critical fixes. I
> > > assume that turns into a branch in git.
> > Amen. We should release 1.0.1 that just includes the ntpq fix and the AWS fix (and any other critical fixes). There's been a lot of other churn since the release and that can all be deferred until a 1.1 release.
> I'd prefer to go to an accelerated 1.1
> The main reason is that there isn't just one ntpq fix. There have been a
> whole bunch of small but user-visible and irritating bugs in ntpq
> reporting since 1.0 - we had Hans Mayer from Austria reporting one
> every couple days for a while.
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.
If I were running 1.0 in production (I'm not), then I would want a quick release with just the exact fixes for the serious breakage. I wouldn't be comfortable deploying so many changes in a quick release, where there was one (or a few) key 1-line fixes. If we cut the release with everything, then I would roll my own packages with the specific fixes backported.
What are the optics on a quick release to fix known compatibility bugs with AWS? Mark?
More information about the devel