rocketraman@xxxxxxxxxxx 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'.
--
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
