On Thu, Nov 04, 2010 at 06:47:52PM -0400, Denys Dmytriyenko wrote: > On Thu, Nov 04, 2010 at 11:33:01PM +0100, Eric B?nard wrote: > > Hi, > > > > Le 04/11/2010 23:06, Denys Dmytriyenko a ?crit : > >> On Thu, Nov 04, 2010 at 09:04:43PM +0100, Leon Woestenberg wrote: > >>> Hello all, > >>> > >>> at OEDEM we discussed the need for OpenEmbedded releases. > >>> > >>> - OpenEmbedded releases are planned in certain months, so that we can > >>> plan stabilization efforts in the future. > >>> - Each release is a point release in time. > >>> - A release is a candidate branch point for a stable branch (which can > >>> be maintained by those who use it). > >>> - The next release is planned 2010.12, more specifically December 1st. > >>> That's only four weeks from now. > >>> - The 2010.12 release is hand-picked from a recent testing branch. > >> > >> - OpenEmbedded releases are planned to be time based and happen every 3 > >> month > >> (quarterly), starting with the first one on December 1st. > >> > > - what about a "no major change" freeze period for 2-3 weeks before each > > release to have a enough time to stabilize a little bit the beast ? > > I thought Leon kind of mentioned it in the first bullet point above, but > probably not very clear. And yes, we definitely need a 2-3 weeks "feature > freeze" period for stabilization. Thanks for pointing it out.
what about branching future release those 2-3 weeks ago and keep master for active development? I know it could lower number of people using this future release branch during testing period before release, but still seems better then pushing 3 weeks of commits from my local branch as soon as release is branched and master open for new recipes again. Regards, -- Martin 'JaMa' Jansa jabber: [email protected] _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
