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.
