+1 doing patch releases more frequently, and doing minor releases on a per-need basis and if an RM volunteers to drive a minor version.
Every minor release we do will come up with its own branch, and we might end up with a lot of active branches to accept bug fixes which might put some burden on the committers to check in to so many branches. Enis On Thu, Mar 5, 2015 at 1:04 PM, lars hofhansl <[email protected]> wrote: > I'd say as long as there are folks who contribute patches we can do patch > releases for older minor releases. It's open source :) > > Keeping *all* minor releases alive seem onerous (there could be dozens - > unless we significantly drive down the time between major releases).Could > do the Linux model and support some minor versions a bit longer than others. > Putting myself in Salesforce's (where I work) shoes... We'd move from > minor or patch release to the next at our own pace. On a case-by-case basis > we'd decide whether to deploy a patch release, wait a bit, or move to the > next minor release.HBase is nicely managed in terms of stability and > compatability, so as along as minor releases are rolling upgradable (with > some versions skipped - i.e. we could go from (say) 1.1.2 to 1.2.7) we'd > likely be following the minor versions mostly. > We would *very* rarely switch major-version as client-server > incompatibilities are very hard to handle for us.I don't think as far as > big shops go we're very special...? > > Maybe we'd have to play this by ear... Start making new minor versions, > and see how much work it is to maintain the older ones and what our users > end up doing (staying on a minor version or adopting new minor versions). > > This is a very interesting topic. > > -- Lars > > From: Sean Busbey <[email protected]> > To: dev <[email protected]> > Cc: lars hofhansl <[email protected]> > Sent: Thursday, March 5, 2015 12:48 PM > Subject: Re: Minor release cadence for branch-1 > > It sounds to me like we have consensus around monthly for patch releases > and minor releases on demand, provided we can find RMs. > > Would it be reasonable to keep all the minor release lines active until we > have a newer major release? At that point we could keep just the most > recent minor release going so long as there's demand. > > -- > Sean > > > On Mar 5, 2015 2:23 PM, "lars hofhansl" <[email protected]> wrote: > > > Any further comments on this? > > Seems important to get agreement at least generally. > > -- Lars > > From: lars hofhansl <[email protected]> > > To: "[email protected]" <[email protected]> > > Sent: Monday, March 2, 2015 10:26 PM > > Subject: Re: Minor release cadence for branch-1 > > > > Hmmm... > > > > I had only expect a monthly patch cadence for minor release (btw, we > > started monthly releases with 0.94.x). > > > > In 0.94 and 0.98 we had no clear distinction between patch and minor > > releases. > > > > For minor releases it seems an on-demand model is more what we want. I.e. > > we'd have a monthly 1.0.1, 1.0.2, etc. Then at some point we'd release > > 1.1.0... "when it's ready". > > Since that's a minor upgrade we can then have a few more 1.0.x releases > > (like 0.94 is now) and then tell folks to upgrade to 1.1.x. > > (in the end, though, patch releases should continue as long as folks are > > willing to contribute patches) > > > > I'd be happy to sign up to do a few minor (1.1, 1.2, or whatever) > releases > > - but I do think we should share the love not have the same folks do > > multiple releases simulataneously. > > > > -- Lars > > > > > > From: Sean Busbey <[email protected]> > > > > > > To: dev <[email protected]> > > Sent: Friday, February 27, 2015 10:06 AM > > Subject: Minor release cadence for branch-1 > > > > Hey folks! > > > > Apologies if I've overlooked this getting discussed already. Do we have a > > goal release cadence for minor versions out of branch-1? > > > > My first gut reaction is that it should essentially match the cadence > we've > > been aiming at for the 0.98 line. That would mean attempting to match > > monthly, I think? > > > > The obvious problem with this is that now that we have patch versions, it > > means essentially getting a new branch per month for backports. That's > > quickly going to get old, even if we presume most additions will move > onto > > branch-2 in a year or so. > > > > What do folks think about limiting which minor versions patch-level fixes > > go into? We could default to the most recent release + current minor dev > > and go back farther when requested by the issue filer? > > > > That means in ~3 months we'd expect branch-1 to be working on 1.4 and > most > > patch-level fixes to go into branch-1.3 and branch-1. If someone > reported a > > failure and they were on e.g. 1.1.z, we'd also do the fix in branch-1.1 > and > > branch-1.2. > > > > Or should we just stick with hitting all of the branches on the > presumption > > that the cherry picks should be trivial? > > > > -- > > Sean > > > > > > > > > > > > > >
