Fellow developers,

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).
git log 

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.


Thanks,
Hari


-- 
Hari Shreedharan


Reply via email to