I am planning on sticking to monthly release candidates for the 1.0.x series of releases. The patches are somewhat controlled, so testing should not be a huge effort.
However, 1.x series are expected to contain new features, and much more change (1.1 already contains some big features on top of 1.0). Thus testing at scale becomes really important before the release. Also my experience is that: 1. People do not upgrade their HBase that frequently. This is expected, since it is a database after all, we are not a library. 2. Testing the release candidate is A LOT of work. I would rather have less number of better tested minor releases. Monthly minor releases will be too much effort IMO. However, upgrading patch versions 1.x.y -> 1.x.z should be a relatively "safe" option, so more frequent patch releases makes sense. My current understanding is that if a new feature lands in master, there is no reason to not bring it to 1.x branches other than (1) the feature is not BC according to semver. (2) the release branch for the next 1.x is not cut yet (which is a timing issue), (3) the feature is not stable enough for 1.x. Enis On Fri, Feb 27, 2015 at 10:36 AM, Andrew Purtell <[email protected]> wrote: > I would volunteer to RM a 1.1 line should we want one. See the discussion > on HBASE-12972 and HBASE-12975 for some motivation in that respect. There > are some supportable interfaces we are working on to make life easier for > both HBase and Phoenix developers going forward that missed 1.0.0 and > probably will need to start life in 1.1.0. > > > On Fri, Feb 27, 2015 at 10:33 AM, Nick Dimiduk <[email protected]> wrote: > > > I don't think we have enough release managers or enough bandwidth as a > > community to evaluate RC's for a monthly minor release cycle. My > > understanding was that we'd continue doing patch releases on the monthly > > cycle (RM's willing) and spin minor releases as we have new RM's > volunteer. > > I don't think we've had a discussion about how long we'd like a minor > > release to stay active in the post-1.0 world, so this is a good topic to > > broach. > > > > That is, of course, unless Enis signed up to RM the whole 1.x release > > lifecycle. In which case, he has right of first refusal on the whole > > line. That was not my understanding, however. > > > > -n > > > > On Friday, February 27, 2015, Sean Busbey <[email protected]> wrote: > > > > > 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 > > > > > > > > > -- > Best regards, > > - Andy > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > (via Tom White) >
