hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lars hofhansl <la...@apache.org>
Subject Re: Minor release cadence for branch-1
Date Thu, 05 Mar 2015 21:04:17 GMT
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 <busbey@cloudera.com>
 To: dev <dev@hbase.apache.org> 
Cc: lars hofhansl <larsh@apache.org> 
 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.


On Mar 5, 2015 2:23 PM, "lars hofhansl" <larsh@apache.org> wrote:

> Any further comments on this?
> Seems important to get agreement at least generally.
> -- Lars
>      From: lars hofhansl <larsh@apache.org>
>  To: "dev@hbase.apache.org" <dev@hbase.apache.org>
>  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 <busbey@cloudera.com>
>  To: dev <dev@hbase.apache.org>
>  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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message