The Flume PMC has decided to keep an active release branch along with trunk. All commits that go into trunk will also have to be committed using git cherry-pick and pushed to the current release branch.
This does not change anything for contributors, but changes the workflow for committers.
Committers should first commit the patch to trunk on your local repo:
git commit (Enter commit message).
Copy the commit hash of the commit you just made. Then:
git checkout flume-1.2.0 (or the current release branch)
git cherry-pick <commit hash of the commit you made> (This should get committed immediately).
Now push to both trunk and the release branch:
git push -u origin trunk
git push -u origin flume-1.2.0
The committer should make sure the commits are pushed to both branches. Please make sure all commits to the release branch are fast forward commits and there are no merge commits on the release branch.
This process requires a little more work, but this guarantees that our release tags will not have accidental and local commits in its history, as we can force push to the release branches to remove these from history. Ideally we should try to keep the history on release branches linear, but if at some point we decide to start using feature branches, we might end up having merge commits on these branches too, but that is expected and required - since that would represent the list of commits for that feature.
I will update the website soon with this information. Please let me know if you have any questions - which I expect many would have.