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@ntpsec.org> wrote: > > rlaa...@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 > scheduled. > 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 > changes > > 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 > where > 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@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > -- Mark Atwood http://about.me/markatwood +1-206-604-2198
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel