prep for 1.0.1
fallenpegasus at gmail.com
Mon Feb 26 16:17:39 UTC 2018
I am inclined towards quarterly release schedule as well, modified with
doing a release when we discover an important enough issue, and we will
delay a release if we discover an important enough issue.
On Wed, Feb 21, 2018 at 1:41 PM Hal Murray via devel <devel at ntpsec.org>
> rlaager at wiktel.com said:
> > If you're going to move to time-based, you might consider quarterly
> > releases?
> I'd be happy with quarterly releases.
> The next question is how seriously do we take the release date? I think
> there are two approaches. The first is to try hard to release as
> That means we have to be conservative and leave plenty of time for testing
> and the associated cleanups. The other approach is to leave less time for
> testing but slip the release if/when we find interesting problems.
> > Longer release cycles allow developers and users of git to test some
> > longer, but that's only helpful if you have a freeze.
> I'm assuming there will be a freeze. Or at least a cooling off period
> the changes are small and reviewed carefully, maybe smaller and more
> carefully reviewed and tested as we get closer to the release.
> There might be a need for more time between releases if we ever make a big
> change. I don't have any good examples right now.
> These are my opinions. I hate spam.
> devel mailing list
> devel at ntpsec.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel