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 <bus...@cloudera.com> 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 >
