[Plplot-devel] git workflow plans for the proposed bug-fix plplot-5.14.1 release

[Alan W. I. <Ala...@gm...>]

Can some git guru here review my proposed git workflow for the planned
5.14.1 release below?

The reason I ask for that review is because I currently have no
practical experience with some of the special git commands that will
be needed.  In fact, because of that lack of experience I previously
did not create a bug-fix release in an earlier release cycle for
PLplot (at least in its git era) when I likely should have!  So this
bug-fix release will be a long-overdue learning experience for me.

That said, I am pretty sure from reading on-line material and a hint
from one of our users what git steps I would have to take.  Also note
these proposed steps do not violate our (enforced) workflow rule that
no merge commits other than fast-forwarded ones are allowed.

Those git steps are as follows:

* Create a local branch called 5.14.0-bugfix from the existing plplot-5.14.0 tag.

* Cherry pick bug-fix commits such as plplot-5.14.0-8-gdb9d90d0b onto that branch.

* Go through the usual release procedure while staying strictly on
   that branch which will add other commits to that branch such as the
   new (short) release notes and ChangeLog for that 5.14.1 release
   without ever merging those commits back to master.  Which means none
   of this bugfix release work impacts on the ordinary development of
   the master branch.  One of the last steps in that procedure would be
   to push the local tag that points to the tip of 5.14.0-bugfix
   (called plplot-5.14.1 in this case) to our SF git repository (again
   without changing the master branch).

* From remarks in
   <https://stackoverflow.com/questions/9265278/what-happens-if-i-push-a-tag-for-a-commit-that-hasnt-been-pushed>
   it appears that pushing a tag pushes the associated commit and also
   pushes all ancestors of that commit that have not been pushed
   before.

   If that is correct, then all commits on my local branch called
   "5.14.0-bugfix" will end up accessible at SF but not organized as a
   formal branch there.  That result is fine with me since it doesn't
   clutter the SF version with extra branch names, and the result is
   enough to allow anybody (after they use the "git refresh" command)
   to access the commit corresponding to the plplot-5.14.1 tag or any
   of that commit's ancestors.  For example, if later on during the
   release cycle I decided to release another bug-fix release called
   5.14.2, I could start that process by branching from the
   plplot-5.14.1 tag.

   Furthmore after pushing the plplot-5.14.1 tag I would likely delete
   the 5.14.0-bugfix local branch to be consistent with the SF repository;
   I would have no further use for that branch; and
   that branch deletion does not get rid of the plplot-5.14.1 tag,
   the associated commit or any ancestors of that commit;

   Of course, with this model of workflow for bug-fix releases, no
   attempt would ever be made to merge bug-fix branches back to master
   since that makes no sense in any case and would violate our
   (enforced) rebase work flow rule that there can be no merge commits
   that cannot be fast-forwarded.

Again, comments on this plan from the git gurus here will be most welcome.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________