From: rocketraman@fastmail.fm
To: git@vger.kernel.org
Subject: [PATCHv2] Update gitworkflows man page to include release workflow
Date: Tue, 10 Nov 2009 11:08:59 -0500 [thread overview]
Message-ID: <1257869339-15999-2-git-send-email-rocketraman@fastmail.fm> (raw)
In-Reply-To: <1257869339-15999-1-git-send-email-rocketraman@fastmail.fm>
From: Raman Gupta <raman@rocketraman.com>
The gitworkflows man page currently provides an overview of the workflows
used by git.git itself to serve as inspiration for people to use when
designing their own workflows. The current man page does a reasonable
job at describing the development process, but it does not contain any
guidance as to the workflow used for releases. Now add a basic
introduction to the branch management required for a release, so that a
reader may understand how the maint, master, next, and topic branches are
affected.
---
Documentation/gitworkflows.txt | 97 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 97 insertions(+), 0 deletions(-)
diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
index 2b021e3..69b789a 100644
--- a/Documentation/gitworkflows.txt
+++ b/Documentation/gitworkflows.txt
@@ -348,6 +348,103 @@ 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 X.Y.Z" vX.Y.Z master`
+=====================================
+
+
+Maintenance branch update
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Maintenance fixes for the current feature release are tracked on the
+'maint' branch.
+
+
+In order to track maintenance
+fixes to the current release, the maintainer uses a branch called
+'maint'.
+
+
+The current maintenance branch is optionally copied to another branch
+named with the older release version number (e.g. maint-X.Y.(Z-1)
+where X.Y.Z is the previous release). This allows for further
+maintenance releases on the older codebase.
+
+If the current tip of 'maint' corresponds to the previous release
+tag (i.e. that there are no fixes already pending on 'maint' that are
+intended for a maintenance release on the older codebase), then
+creating the 'maint' branch for the older codebase can also be done
+later, if it is needed.
+
+.Copy maint
+[caption="Recipe: "]
+=====================================
+`git branch maint-X.Y.(Z-1) maint`
+=====================================
+
+'maint' should 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 updates 'maint' from 'master', while preserving the 'maint'
+reflog.
+
+An alternative approach to updating the 'maint' branch is to run
+
+ $ git branch -f maint master
+
+This will create a new 'maint' branch based on 'master'. If 'maint'
+already exists, it will be deleted before the new branch is created.
+Any commits on 'maint' that were not previously merged to master will
+therefore be lost and the 'maint' reflog will be reset. However, the
+branch history is "clean" and may be easier to understand.
+
+
+Update next branch
+~~~~~~~~~~~~~~~~~~
+
+The 'next' branch may be rewound and 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 rewound and
+rebuilt.
+
+.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
next prev parent reply other threads:[~2009-11-10 16:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-10 16:08 Update gitworkflows man page to include release workflow rocketraman
2009-11-10 16:08 ` rocketraman [this message]
2009-11-10 18:06 ` [PATCHv2] " Štěpán Němec
2009-11-10 18:10 ` Raman Gupta
2009-11-11 13:05 ` Thiago Farina
2009-11-11 15:23 ` Raman Gupta
2009-11-11 19:43 ` Junio C Hamano
2009-11-12 0:32 ` Raman Gupta
2009-11-12 8:03 ` Junio C Hamano
2009-11-12 8:10 ` Thomas Rast
2009-11-12 16:54 ` Raman Gupta
2009-11-11 20:41 ` Thomas Rast
2009-11-12 8:27 ` Thomas Rast
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1257869339-15999-2-git-send-email-rocketraman@fastmail.fm \
--to=rocketraman@fastmail.fm \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).