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

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