Preparing for a point release

[Matthew Selsky]

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?


Thanks,
-Matt