[ntp:hackers] hackers] Post 4.2.8 Release Number Scheme

Harlan Stenn stenn at ntp.org
Thu Jan 2 19:52:34 UTC 2014


Brian Utterback writes:
> Um, yes, that is what it already said. Repeating it doesn't help me. I 
> understand what it means from the consumer side. What I don't understand 
> is how it works from the development side. Suppose we wanted a new 
> stable release every year. How is that accomplished? First six months 
> open changeset commit, then a dev release, followed by a branch with a 
> new -RC branch?  Then six months of open development on the main branch 
> and bug fixes only on the -RC branch? Then after six months the RC 
> branch becomes the new stable release? Is that how it works or something 
> else? If so, what is the point of having the development release?

I'm not planning any changes to the process.

We do development on the -dev release.  We request that some bugs
"block" the next release.  When we decide to start a release cycle we do
a feature-freeze, I make a pass over the open bug list and make
adjustments to the "blocking" status of bugs.  We focus on resolving
these blockers, and at some point we either get them all and I cut a
release, or I decide that I'm gonna let some of the blockers slide and I
cut a release.

Cutting a release means:

ntp-dev-4.2.5pNNN-RC gets some changes to packageinfo.sh and becomes
ntp-4.2.6 in the -stable repo.

After that release fully rolls I pull -stable into -dev, and make some
changes to packageinfo.sh in ntp-dev and release ntp-dev-4.2.7p0.

At any time, if somebody finds a bug that they think should be fixed in
-stable they open a report and request that it blocks the current
-stable release.  If that's a reasonable thing to do, we grant that as
blocking the stable release, and fix it in -stable and -dev.  We
generally do the testing of this in -dev.  When we're satisfied, we cut
a new -stable point release.

While I'd like to see NTP releases happen every year, reality bites.
It's already been longer than I'd like on the 4.2.8 cycle, and the good
news is that we're very close - I'm working hard on the autogen
documentation generation issues and I gather some other folks are
looking at the IPv6 and non-unicast network issues.  There may be some
other folks working on some other blockers, too.

H


More information about the hackers mailing list