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?
Initially we probably don't need to do this, but I just want to make sure that we pick a release model that will also work if we need to put more effort into stabilising releases. 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. On Tue, Jun 7, 2016 at 8:59 AM, Jim Apple <[email protected]> wrote: > How should Impala branches be a manged? > > Today, most of our new development happens on trunk, except when a CDH > release is imminent. I propose we move to a time-based release model, > where development happens on the "master" branch and every N weeks a > commit that is passing all of the tests is tagged with a version > number. > > Then we can do an actual release: http://www.apache.org/dev/release.html > > For big breaking changes, we could keep two branches around > corresponding to the two versions currently being developed on. > > Thoughts? >
