Re: [PATCH 2/2] Add feature release instructions to gitworkflows man page

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 26, 2009, 06:48 UTC
Message-ID: <7veiwksrsr.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <1238032575-10987-2-git-send-email-rocketraman@fastmail.fm>

rocketraman@fastmail.fm writes:

Show 11 quoted lines

> +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.

Show 12 quoted lines

> +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.

Show 8 quoted lines

> +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'.