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 __________________________ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
