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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano wrote:
> 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.

Fixed.

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

Yeah, I originally had written "Copy maint" but copy seemed to be more
subversion-speak rather than git-speak so I changed it. However it
does seem to accurately describe the operation. Would "Copy maint" be
acceptable terminology?

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

Fixed.

Cheers,
Raman
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux