Thread (4 messages) flat view 4 messages, 2 authors, 2016-06-15

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

From: Raman Gupta <hidden>
Date: 2016-06-15 22:46:28

Junio C Hamano wrote:
rocketraman@fastmail.fm writes:
quoted
+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.
quoted
+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?
quoted
+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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help