Paul, et. al., 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 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/