Also note that I have cherry picked all commits till this morning. Any further commits will have to be handled by the committer who commits it to trunk.
Thanks Hari -- Hari Shreedharan On Friday, August 24, 2012 at 12:50 PM, Hari Shreedharan wrote: > 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
