A reasonable policy could be: - Bug fixes ported back two releases (so that's 0.94 and 0.92) if applicable for the respective code base.
- Releases > 2 major versions back are "best effort". Assuming a committer has an interest. I'm guessing Ram et. al. may have an interest in 0.90 branch for a while. - No major user facing functionality changes: new UI, PB, etc. - Build system changes and support like integration tests don't have an end user impact so could be ok. On Mon, Aug 20, 2012 at 12:18 PM, Stack <[email protected]> wrote: > On Mon, Aug 20, 2012 at 11:16 AM, Enis Söztutar <[email protected]> > wrote: > > 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? > > > > I'd think that 0.94 branch gets bug fixes only. Anything else than > that gets confusing. > > Do we want to have a 0.96 release that is not pb, branched from 0.94? > Into this 0.96 we'd backport non-pb stuff -- tests and 'safe' > features? > > pb could then come out in a 0.98? > > (Let me start a 0.96 thread. I think we're close) > > St.Ack > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
