Yeah actually that doesn't make sense. Why have the release sit around for a month instead of fixing bugs in it right to the end of the SR?
Sent from my BlackBerry 10 smartphone on the Rogers network. From: Igor Fedorenko Sent: Wednesday, August 14, 2013 11:24 AM To: [email protected] Reply To: Cross project issues Subject: Re: [cross-project-issues-dev] Question on Kepler SR1 release review Is "new releases must be released a month before SR RC1" a new requirement? -- Regards, Igor On 2013-08-14 6:53 PM, David M Williams wrote: > I'll take this topic as a good segue to summarize Planning Council's > view on "more frequent releases" and "including new features in SRs". > I'll try to keep in brief, but anyone is welcome to read my full notes > of meeting at http://wiki.eclipse.org/Planning_Council/August_7_2013 > > First, it was recognized our "slow pace" was not satisfying all projects > and adopters, but ... > Second, it was satisfying most, so the short answer is status quo > continues ... though we committed to continue the discussion for the > long term. Its just that no one knew of any "easy answers" that could be > implemented easily, without requiring more work from everyone. > > The "status quo" is captured in our current policy statement, at > http://wiki.eclipse.org/SimRel/Simultaneous_Release_FAQ#Can_a_new_project_or_feature_join_a_Simultaneous_Service_Release_.28SR1_or_SR2.29.3F > > > In fact, it turns out several strategic adopting members were surprised > we allow new features at all ... and wanted the emphasis to stay on bug > fixes and quality improvements in the SRs, and to not "be surprised" by > new features. So, we humbling ask projects to announce and summarize > here on cross-project list when they are adding new features and when > "minor" versions increment. We definitely want to allow projects to add > new features when they need to, based on the needs of their community > and adopters ... but don't want to encourage "experiments" with new > features that might not be fully baked yet. So, we'll stick with the > restrictions that "new releases" must be released a month before RC1 and > "be in" RC1, as our policy states. > > This does not prevent any project from having a new release anytime you > want .... but might mean you can not contribute it to "Simultaneous > Release maintenance". > > Hope this helps adds clarity to the current rules for "Simultaneous > Release maintenance". > > Thanks, > > > > > From: Gunnar Wagenknecht <[email protected]> > To: Cross project issues <[email protected]>, > Date: 08/14/2013 08:55 AM > Subject: Re: [cross-project-issues-dev] Question on Kepler SR1 release > review > Sent by: [email protected] > ------------------------------------------------------------------------ > > > > Am 14.08.2013 um 02:41 schrieb Matthias Sohn <[email protected]>: > > AFAIK if you want to release a pure maintenance release (only > bugfixes, no new features) > > you don't need a release review, if you want to ship new features you > need the review. > > Yes, this is correct. Technically, a pure maintenance (aka. service) > releases changes only the 'x' of 'a.b.x' version string. > > -Gunnar > > -- > Gunnar Wagenknecht > [email protected] > > > > > > _______________________________________________ > cross-project-issues-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > > > _______________________________________________ > cross-project-issues-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
