Below is some elaboration of what I am proposing. Keep in mind that this is not set in stone. It can change at any time the Apache Impala (incubating) community wants to change it.
Additionally, not much of this is required by the ASF. The ASF requires that a releases happen before graduation in order to verify that the community is capable of doing so. So, the proposal: Generally, active development should happen on "master". There are two exceptions: 1. From time to time, the community will cut a release. The responsibility to release is not a responsibility of any one person, but of the community as a whole. However, the responsibility for a particular release will be held by one person (or a group of volunteers) per release. There is no set schedule for releases. If a community member wants to cut a release and the PMC votes against it, no release will be created. Potential release managers should discuss release plans with the community and then hold a vote before starting the release work. Releases must follow the ASF guidelines: http://www.apache.org/dev/release.html#owned-controlled-hardware Releases must also pass all tests in the repository. The PMC has the responsibility for checking the releases: http://www.apache.org/dev/release.html#approving-a-release Each release will get its own branch. This branch will hold a snapshot of the code as of a certain date as well as any cherry-picked patches from other branches (presumably mainly "master") as the release manager thinks appropriate. Generally, after release, branches will not receive a lot of attention. This means they are unlikely to receive backported fixes from "master". Users who want to include those fixes can wait until the next release or build their own custom version. This policy can be modified on a branch-by-branch basis by lazy consensus. It is a responsibility of the community to cut a release before making big breaking changes to "master" that would constitute a "major" release. 2. Feature branches may be created for speculative work that will take a a sequence of changes to be fully realized. These feature branches should be approved before being opened by lazy consensus: https://community.apache.org/committers/lazyConsensus.html The goal of the committers on any feature branch should be to eventually get that branch merged back into "master". Feature branches can be merged back into "master" by a vote of the PMC. Feature branches that have lost all of their momentum can be closed by a vote of the PMC. +++++++++++++++++++++ Thoughts? On Thu, Jun 9, 2016 at 10:52 AM, Jim Apple <[email protected]> wrote: >> 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. > > That sounds good to me. It is my understanding that the way Kudu does > it is that someone generally volunteers to drive the next K releases, > anticipating creating the release branch every N weeks. > >> 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. > > SGTM > >> 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. > > SGTM. > > Does anyone else have concerns about this branching model?
