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 20:19:34 GMT
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


  

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