Ah, I didn't realise you were thinking about Impala 3.0. My feeling is that we should try to minimise disruption to the regular development process on trunk. We could draw a line at some release as the last 2.x release, and once that's branched from trunk, breaking changes for 3.0 can go in. Depending on how long the window between the last 2.x release and the 3.0 release, that might mean we have to skip some releases that have breaking changes, or we could just make them 3.0 "preview" releases.
On Tue, Jun 7, 2016 at 10:24 AM, Henry Robinson <[email protected]> wrote: > On 7 June 2016 at 09:56, Jim Apple <[email protected]> wrote: > > > Thank you. I think these are good questions. > > > > > What would happen if we discover that a tagged release has a critical > bug > > > that was missed by the test cases? Would we have a release branch to > > > stabilise the release with any critical fixes? > > > > I think that is the right choice. What do you think? > > > > In other projects I've been involved in, that release would be pulled from > the distribution pages, and another release (with an incremented version > number) would be published. Once a version is released, it's pretty > immutable. Releasing from a branch seems the only sane way to do that. > > For a release to happen, someone has to volunteer to be a release manager > and go through the process of shepherding in all the needed fixes, getting > the tests passed, dealing with release mechanics (signing, license checks > etc) and getting the vote passed. Since that's not totally lightweight, I > don't think we should force the project into a regular every-N-weeks > cadence without being sure that the release process can keep up. > > Instead, if some of the committers want to keep up with that rough cadence > they should volunteer every N weeks - the distinction I'm trying to draw is > between a predetermined release cycle, and a best-effort one that makes > explicit the need to rely on volunteers to drive each release. > > > > > > > Were you thinking of the scenario where we're trying to stabilise a > > release > > > on trunk at the same time as a major feature is in development? I'm > not a > > > big fan of long-lived feature branches: I think it's a last resort if > > > changes can't be staged in trunk in a sensible non-breaking way. > > > > For "big breaking changes", you mean? I was thinking of the things > > that would cause us to move to Impala 3.0, rather than a long-lived > > feature branch. > > > > Do you think Impala 3.0 development should happen on "master"? > > > > I do. At some point before we start taking breaking changes we should cut a > 2.X sustaining branch so that anyone who wants to make further release off > the 2.X series can do so. > > However, I also think there's a place for individual feature branches, as > long as they are usually merged back to trunk after the branch meets its > requirements. A good example is the PPC work - it's a good idea to get that > stable before it's merged to trunk, but once it's merged, the branch > shouldn't be needed any more. > > Long-lived feature branches are a pain, but we shouldn't rule them out > entirely if some contributors want to undertake speculative work. >
