prep for 1.0.1

Mark Atwood fallenpegasus at
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>

> rlaager at 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 at

Mark Atwood
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the devel mailing list