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) [email protected] (web) http://www.cpbibliography.com/
_______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
