<div dir="ltr"><div dir="ltr"><div>Hi all,</div><div><br></div><div>I'd like to propose a change to <a href="https://wiki.evergreen-ils.org/doku.php?id=dev:release_process:evergreen:how_to_build" target="_blank">the release process</a> (how original, I know!).  Currently, we make certain commits only in the tag branch for a specific release (e.g. tags/rel_3_12_2), and others in both the tag branch and the release series branch (e.g. rel_3_12).</div><div><br></div><div>These go into both:</div><div><ul><li>The database upgrade script (depending on the branch, this can be found in commits called "Forward-port[...]" or "Bumping version numbers, adding Upgrade Script[...]")</li><li>The release notes</li><li>Untranslated strings that are bound to launchpad (in commits called "Translation updates - newpot")</li></ul></div><div><br></div><div>These go only into the tag branch:</div><div><ul><li>Updates to translated strings from both launchpad and PoEditor</li><li>Bumping the version string in Open-ILS/src/perlmods/lib/OpenILS.pm</li><li>Bumping the version string in Open-ILS/src/perlmods/lib/OpenILS/Application.pm</li><li>Putting an actual version (instead of 3.X.X) into docs/modules/installation/pages/server_upgrade.adoc</li><li>The Changelog</li><li>An upgrade_log sql statement in 002.schema.config.sql.</li><li>Some XUL stuff, apparently.</li></ul></div><div><br></div><div>My proposal would be to make all needed changes to the release series branch, and then create the tag branch directly from the release series branch when all these steps are done.  So, at the time of release, rel_3_12 and tags/rel_3_12_2 would be identical, before rel_3_12 starts to accumulate bug fixes for the next release.</div><div><br></div><div>From my limited perspective, here are the pros:</div><div><ul><li>It would eliminate any errors that could arise through differences in the release series branch and the release tag branch (e.g. not forward-porting the upgrade script to rel_3_12)</li><li>We'd keep po files in the git repo, making it easier to see what has changed from release to release, and making it easier to set up a localized environment from the git source.</li><li><a href="https://docs.evergreen-ils.org/docs/3.12/installation/server_upgrade.html#_upgrade_the_evergreen_code" target="_blank">Our public documentation</a> would include the actual version numbers and file names for the most recent release in a series, rather than a bunch of Xs. </li><li>Manually changing the version string in Open-ILS/src/perlmods/lib/OpenILS.pm would be less of a brain teaser each time (this may be a personal problem, but it is easier and less error-prone to just increment the number that's already there than delete "2.4" and try to figure out the correct format from scratch).</li><li>I tend to visit the release series branches more often than the release tag branches.  For those like me, it can make the release process more visible.</li></ul></div><div><br></div><div>Cons:</div><div><ul><li>Having these things in the release series branch may cause some kind of problem that I'm not familiar with.</li><li>People may have tools that help them roll releases that would need to be changed.</li></ul></div><div><br></div><div>Please let me know your thoughts, especially if there are any cons that I have missed, or prerequisites we would need before making such a change.  I'm not proposing this for the in-progress 3.11.4 release, by the way, just for the future.</div><div><br></div><div>Thanks for considering!</div><div><br></div><div>  -Jane</div><div><br></div></div></div>