Author: hshreedharan
Date: Fri Aug 24 20:06:16 2012
New Revision: 1377079
URL: http://svn.apache.org/viewvc?rev=1377079&view=rev
Log:
Updating Flume development information and use of release branches.
(Hari Shreedharan)
Modified:
flume/site/trunk/content/sphinx/source.rst
Modified: flume/site/trunk/content/sphinx/source.rst
URL:
http://svn.apache.org/viewvc/flume/site/trunk/content/sphinx/source.rst?rev=1377079&r1=1377078&r2=1377079&view=diff
==============================================================================
--- flume/site/trunk/content/sphinx/source.rst (original)
+++ flume/site/trunk/content/sphinx/source.rst Fri Aug 24 20:06:16 2012
@@ -19,6 +19,10 @@ The following is a link to the online so
.. rubric:: Anonymous Access
+Flume maintains an active release branch along with trunk. The release branch
represents the list of commits that will go into the next release.
+All commits that go into trunk will also have to be committed using git
cherry-pick and pushed to the current release branch.
+The current release branch is flume-1.3.0.
+
The source can be checked out anonymously from git with this command:::
$ git clone http://git-wip-us.apache.org/repos/asf/flume.git flume
@@ -29,17 +33,40 @@ Everyone can access the Git repository v
$ git clone https://git-wip-us.apache.org/repos/asf/flume.git flume
-To commit changes to your local repository, execute the following command to
commit your changes::
+Committers should first commit the patch to trunk on your local repo::
$ git commit -m "A message"
+ $ git log
+
+Copy the commit hash of the commit you just made. Then::
+
+ $ git checkout flume-1.3.0 (or the current release branch)
+ $ git cherry-pick <commit hash of the commit you made> (This should get
committed immediately).
-To push this to the Apache repository, execute the following command::
+Now push to both trunk and the release branch::
$ git push -u origin trunk
+ $ git push -u origin flume-1.3.0
For more details, please read: `Git at Apache
<https://git-wip-us.apache.org/>`_. Please read the
`Common Errors page <https://git-wip-us.apache.org/docs/common-errors.html>`_
if you face any problems.
+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.
+
+When a release is finalized, the current release branch will be frozen by the
release manager for the release, and a new release branch will be
+branched off the current release branch. The new branch will represent the
next release and all commits not meant for the current release must
+go to the new branch once the current branch is frozen. The release manager
then pushes release related commits to the current branch.
+
+For example, if the next release is flume-1.3.0, and it is finalized, the
release manager will create a new branch, say flume-1.4.0 from the latest
commit of
+flume-1.3.0. All further non-release related commits should go to trunk and
flume-1.4.0 (unless the release manager thinks otherwise - in which case it can
+go to flume-1.3.0 and flume-1.4.0).
+
Please note that the main development branch is **trunk**, not master.
.. rubric:: Access From Behind a Firewall