[Evergreen-dev] Release branch proposal

[Jane Sandberg]

Hi all,

I'd like to propose a change to the release process
<https://wiki.evergreen-ils.org/doku.php?id=dev:release_process:evergreen:how_to_build>
(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).

These go into both:

   - The database upgrade script (depending on the branch, this can be
   found in commits called "Forward-port[...]" or "Bumping version numbers,
   adding Upgrade Script[...]")
   - The release notes
   - Untranslated strings that are bound to launchpad (in commits called
   "Translation updates - newpot")


These go only into the tag branch:

   - Updates to translated strings from both launchpad and PoEditor
   - Bumping the version string in Open-ILS/src/perlmods/lib/OpenILS.pm
   - Bumping the version string in
   Open-ILS/src/perlmods/lib/OpenILS/Application.pm
   - Putting an actual version (instead of 3.X.X) into
   docs/modules/installation/pages/server_upgrade.adoc
   - The Changelog
   - An upgrade_log sql statement in 002.schema.config.sql.
   - Some XUL stuff, apparently.


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.

>From my limited perspective, here are the pros:

   - 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)
   - 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.
   - Our public documentation
   <https://docs.evergreen-ils.org/docs/3.12/installation/server_upgrade.html#_upgrade_the_evergreen_code>
   would include the actual version numbers and file names for the most recent
   release in a series, rather than a bunch of Xs.
   - 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).
   - 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.


Cons:

   - Having these things in the release series branch may cause some kind
   of problem that I'm not familiar with.
   - People may have tools that help them roll releases that would need to
   be changed.


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.

Thanks for considering!

  -Jane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/evergreen-dev/attachments/20240226/6af52b50/attachment.htm>