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)
