I just wanted to express my support for this plan on the mailing list.
What I/we plan to do:
* 2 months before the release (number N) =
- declare small feature freeze: only bugfixes and small/non-core
enhancement are pushed for the next release
- branch the release on git. master goes his way for N+1, major ENH
can be pushed here. N is still controlled by the RM, N-1 controlled by
the RMaint
* 1 month before the release =
- declare string freeze: no more string changes to let translators
do their work
+1
By "are pushed" I really mean the freeze is about *pushing* before the
freeze. In previous releases, we've accepted some ENH provided they've
been *submitted* before the freeze. That's an important change, be
careful ! If we want stability, we need more time to test.
+INFINITY!!!! This is a very good idea.
Last (but not least) point:
* August is holiday time for Northern hemisphere, and oct22 minus 2
months = Aug 22, that's a problem. That's why I propose to switch to
may/november for our releases.
The timeline would be:
* today => sept 22 => hack ! hack ! hack !
* sept 22 => feature freeze, no more large or core enhancements pushed
(whatever the date of submission of the patch)
* oct 22 => string freeze, no more string changes
* nov 22 => Koha 3.10 (and I'm no more RM. Yippee !!! :D :D )
I think with this modified release process we can look forward to the release of 3.10.0 on November 22 as the most stable .0 release yet.
Regards,
Jared
--
Jared Camins-Esakov
Bibliographer, C & P Bibliography Services, LLC
(phone) +1 (917) 727-3445