In my opinion, we should put more emphasis on tackling the blocking issues of 0.96 so that 0.96 RC0 can be rolled some time this year.
Cheers On Mon, Aug 20, 2012 at 4:24 PM, Enis Söztutar <[email protected]> wrote: > If we do branch 0.96 from 0.94, then release current trunk as 0.98, it > might be confusing, no? Maybe a 0.95, if we wanna go that path? > > Andrew and Lars's comments seem reasonable to me. > > Enis > > On Mon, Aug 20, 2012 at 4:18 PM, lars hofhansl <[email protected]> > wrote: > > > Hmm... Reading the other responses... It seems there're more different > > opinions here. > > Thanks for bringing this up Enis. > > > > I can see a 0.96 branched from 0.94 without PB and some of the other 0.96 > > "singularity" features. (Although then the question arises: How would > that > > be different from the 0.94.x?) > > > > > > -- Lars > > > > > > > > ________________________________ > > From: lars hofhansl <[email protected]> > > To: "[email protected]" <[email protected]>; " > > [email protected]" <[email protected]> > > Sent: Monday, August 20, 2012 1:56 PM > > Subject: Re: Porting policy from 0.96+ to 0.94 > > > > Since 0.94 will probably be a long lived version with many releases > > (thinking about 0.94.2 already),we should back port all changes that: > > 1. Do not break client/server compatibility (in both directions) > > > > 2. Do not break server/server compatibility > > 3. Do not rely on extensive refactoring that happened only in trunk > > 4. Are not just cosmetic > > 5. Do not just represent refactoring without any features added or bugs > > fixed > > > > > > It includes bug fixes, performance improvements, even new features, etc. > > But nothing that represents risk without an appropriate benefit. > > > > > > #1 and #2 are hard rules, the rest is obviously subject to > interpretation. > > > > In terms of UI changes. We probably want to keep mere face lifts out, but > > include changes that provide extra information (new metrics, etc). > > We definitely want any integrations tests back ported, unless the > > supporting changes to non-test code are extensive. > > > > > > TL;DR: Back port unless there is a good reason not to; and use good > > judgment. :) I'll be looking at most changes that go into 0.94. > > > > > > Also, please do not assume that 0.96 is planned as an unstable release. > > That is not the case at all. It just might take a while to stabilize. > > > > > > This is just off the top of my head, and as usual just my $0.02. > > > > > > -- Lars > > > > > > > > ________________________________ > > From: Enis Söztutar <[email protected]> > > To: [email protected] > > Sent: Monday, August 20, 2012 11:16 AM > > Subject: Porting policy from 0.96+ to 0.94 > > > > Hi, > > > > Last time we were talking Lars (H.) raised the issue that we might need a > > stable base while 0.96, and its successors are fully baked in for > > production use. So, it seems that 0.94 branch releases will be a > deployment > > target for some time at least on some of the organizations for some time. > > We have been backporting a lot of stuff already from trunk into 0.94, > but I > > want to discuss whether we should establish an "official" policy of what > > should be backported or not. We will definitely want bug fixes in, but > > what about new UI stuff, or integration tests, etc. If we can agree on > > general guidelines at least, it will be then easier to decide on a > > patch-by-patch basis. What do you guys think? > > > > Enis > > >
