From: Raman Gupta <redacted>
Based on a mailing list discussion, add the operations for creating a
feature release.
Signed-off-by: Raman Gupta <redacted>
---
Documentation/howto/maintain-git.txt | 29 +++++++++++++++++++++++++++++
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/Documentation/howto/maintain-git.txt b/Documentation/howto/maintain-git.txt
index 4357e26..f6ee0c5 100644
--- a/Documentation/howto/maintain-git.txt
+++ b/Documentation/howto/maintain-git.txt
@@ -244,6 +244,35 @@ by doing the following:
repo.or.cz
+A feature release of git is made by tagging 'master' with a tag
+matching vX.Y.Z, where X.Y.Z is the feature release version.
+
+ - Optionally, track the current 'maint' branch to support
+ new releases for the older codebase if necessary.
+
+ $ git branch maint-X.Y.(Z-1) maint
+
+ - The 'maint' branch is updated to the new release.
+
+ $ git checkout maint
+ $ git merge master
+
+ This is equivalent to deleting maint and recreating it from
+ master, but it preserves the maint reflog.
+
+ - The 'next' branch may be rebuilt from the tip of 'master'
+ using the surviving topics on 'next'.
+
+ $ git branch -f next master
+
+ (Again, this approach preserves the reflog and per-branch
+ configuration of 'next')
+
+ $ git merge ai/topic_in_next1
+ $ git merge ai/topic_in_next2
+ ...
+
+
Some observations to be made.
* Each topic is tested individually, and also together with--
1.6.2
From: Raman Gupta <redacted>
Based on a mailing list discussion, add a description of the workflow,
and associated commands, for creating a feature release.
Signed-off-by: Raman Gupta <redacted>
---
Documentation/gitworkflows.txt | 69 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 69 insertions(+), 0 deletions(-)
diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
index 2b021e3..1796878 100644
--- a/Documentation/gitworkflows.txt
+++ b/Documentation/gitworkflows.txt
@@ -348,6 +348,75 @@ in patches to figure out the merge base. See linkgit:git-am[1] for
other options.
+RELEASE WORKFLOW
+----------------
+
+The maintainer may use the following release workflow:
+
+He first tags the tip of 'master' with a release tag, then he updates
+the 'maint' branch to the current tip of 'master' for managing future
+maintenance fixes on the current release, and lastly he optionally
+rebuilds 'next' from the tip of 'master'.
+
+
+Release Tagging
+~~~~~~~~~~~~~~~
+
+The new feature release is tagged on 'master' with a tag matching
+vX.Y.Z, where X.Y.Z is the new feature release version.
+
+.Release tagging
+[caption="Recipe: "]
+==========================================
+`git tag -s -m GIT "vX.Y.Z" vX.Y.Z`
+==========================================
+
+
+Maintenance branch update
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The current maintenance branch is optionally tracked with the older
+release version number to allow for further maintenance releases on
+the older codebase.
+
+.Track maint
+[caption="Recipe: "]
+=====================================
+`git branch maint-X.Y.(Z-1) maint`
+=====================================
+
+'maint' is now updated to the new release code so that maintenance
+fixes can be merged for the current version.
+
+.Update maint to new release
+[caption="Recipe: "]
+=====================================
+* `git checkout maint`
+* `git merge master`
+=====================================
+
+This is equivalent to deleting maint and recreating it from master,
+but it preserves the maint reflog.
+
+Update next branch
+~~~~~~~~~~~~~~~~~~
+
+The 'next' branch may be rebuilt from the tip of 'master' using the
+surviving topics on 'next'.
+
+This step is optional. If it is done by the maintainer, then a public
+announcement will be made indicating that 'next' was rebased.
+
+.Update maint to new release
+[caption="Recipe: "]
+=====================================
+* `git branch -f next master`
+* `git merge ai/topic_in_next1`
+* `git merge ai/topic_in_next2`
+* ...
+=====================================
+
+
SEE ALSO
--------
linkgit:gittutorial[7],
--
1.6.2
rocketraman@fastmail.fm writes:
+Release Tagging
+~~~~~~~~~~~~~~~
+
+The new feature release is tagged on 'master' with a tag matching
+vX.Y.Z, where X.Y.Z is the new feature release version.
+
+.Release tagging
+[caption="Recipe: "]
+==========================================
+`git tag -s -m GIT "vX.Y.Z" vX.Y.Z`
+==========================================
I actually always do:
git tag -s -m "GIT X.Y.Z" vX.Y.Z master
The argument to -m in your descriptoin is incorrectly quoted, and has an
extra v. I also spell out 'master' to avoid mistakes, and I would be
happy to encourage others to follow it.
+Maintenance branch update
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The current maintenance branch is optionally tracked with the older
+release version number to allow for further maintenance releases on
+the older codebase.
+
+.Track maint
+[caption="Recipe: "]
+=====================================
+`git branch maint-X.Y.(Z-1) maint`
+=====================================
This creates maint-X.Y.(Z-1) from maint, but calling this step "track
maint" entirely misses the point.
When people use the word "track", the intention is that they intend to
merge subsequent changes to the original branch (in this case, 'maint') to
the new branch ('maint-X.Y.(Z-1)') from time to time.
That is exactly opposite to what I create maint-X.Y.(Z-1) branch for.
This new "branch to maintain an older codebase" will *never* merge from
'maint' after it forks.
+Update next branch
+~~~~~~~~~~~~~~~~~~
+
+The 'next' branch may be rebuilt from the tip of 'master' using the
+surviving topics on 'next'.
+
+This step is optional. If it is done by the maintainer, then a public
+announcement will be made indicating that 'next' was rebased.
The wording I use is more like 'rewound and rebuilt'.
Junio C Hamano wrote:
rocketraman@fastmail.fm writes:
quoted
+Release Tagging
+~~~~~~~~~~~~~~~
+
+The new feature release is tagged on 'master' with a tag matching
+vX.Y.Z, where X.Y.Z is the new feature release version.
+
+.Release tagging
+[caption="Recipe: "]
+==========================================
+`git tag -s -m GIT "vX.Y.Z" vX.Y.Z`
+==========================================
I actually always do:
git tag -s -m "GIT X.Y.Z" vX.Y.Z master
The argument to -m in your descriptoin is incorrectly quoted, and has an
extra v. I also spell out 'master' to avoid mistakes, and I would be
happy to encourage others to follow it.
Fixed.
quoted
+Maintenance branch update
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The current maintenance branch is optionally tracked with the older
+release version number to allow for further maintenance releases on
+the older codebase.
+
+.Track maint
+[caption="Recipe: "]
+=====================================
+`git branch maint-X.Y.(Z-1) maint`
+=====================================
This creates maint-X.Y.(Z-1) from maint, but calling this step "track
maint" entirely misses the point.
When people use the word "track", the intention is that they intend to
merge subsequent changes to the original branch (in this case, 'maint') to
the new branch ('maint-X.Y.(Z-1)') from time to time.
That is exactly opposite to what I create maint-X.Y.(Z-1) branch for.
This new "branch to maintain an older codebase" will *never* merge from
'maint' after it forks.
Yeah, I originally had written "Copy maint" but copy seemed to be more
subversion-speak rather than git-speak so I changed it. However it
does seem to accurately describe the operation. Would "Copy maint" be
acceptable terminology?
quoted
+Update next branch
+~~~~~~~~~~~~~~~~~~
+
+The 'next' branch may be rebuilt from the tip of 'master' using the
+surviving topics on 'next'.
+
+This step is optional. If it is done by the maintainer, then a public
+announcement will be made indicating that 'next' was rebased.
The wording I use is more like 'rewound and rebuilt'.
Fixed.
Cheers,
Raman