rocketraman@xxxxxxxxxxx writes:
> From: Raman Gupta <raman@xxxxxxxxxxxxxxx>
>
> 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.
> ---
Is this meant to show how git.git does its release to serve as an
inspiration to others? The document does not seem to describe how I make
releases.
> 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:
Please set the tone straight. If this is to suggest various possible
workflows in general vague terms, "may use" would be good. If this is to
precisely describe what I do, then there won't be "you could do this, or
you could do that." Your "may use" suggests the former, but the commit
log message claims the latter. Which document are you writing?
Assuming that you are writing what I do...
> +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'.
Not in that order.
- doubly make sure that there is nothing left in 'maint' that
is not in 'master';
- review 'master' more thoroughly than usual;
- review RelNotes symlink, Documentation/RelNotes-X.Y.Z.txt,
the stalenotes section in Documentation/git.git, and
GIT-VERSION-GEN for the last time;
- tag it;
- review it again for the last time;
- test on buildfarm;
- cut tarball;
- cut RPM on FC11 i386 and FC11 x86_64;
- push the tag and master branch alone to the public server---this
triggers an autobuilder for documentation pages, updates man and
html branches and documentation tarballs;
When making a maintenance release, everything is the same except that
'maint' is used instead of 'master'.
Then, after all the release task on 'master' (or 'maint') is done,
propagate that upwards (i.e. merge 'master' to 'next' and 'pu').
Merging 'master' to 'maint' is done totally as a separate step, often a
few days later, "Now the big release is done, let's start maintenance
track for that relase".
And then after that, 'next' may be rebuilt.
> +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`
> +=====================================
There is no incorrect information here, but I do not think there is
anything particularly worth saying here, either. It is in "git tag"
manpage and anybody can run "git cat-file tag v1.6.3" to learn what is in
there.
> +Maintenance branch update
> +~~~~~~~~~~~~~~~~~~~~~~~~~
This section largely overlaps with Documentation/howto/maintain-git.txt; I
am starting to doubt if we even need a new section in the workflows
document. Perhaps we could have a release management section in the
Documentation/howto/maintain-git.txt, though.
> +[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
As I already said, I never do this "alternative", and I do not want
anybody who will take over git.git maintenance to do so. There is no
reason to encourage nor even mention "branch -f" here. As 'maint' is
supposed to be a strict subset, pulling 'master' to 'maint' should fast
forward and otherwise you (the maintainer) would notice that there was a
mistake made. If you use "branch -f", you will never notice.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html