[Evergreen-dev] Release branch proposal

[Blake Graham-Henderson]

Jane,

Thank you for the well-thought-out proposal.

Galen has led a few discussions aiming at completely automating the 
release process. So that we need only to click on "go". I think that's a 
great goal and it seems to align with the spirit of this thread.

If it were completely automated, would the proposed changes for release 
branches matter? In other words: are you making these proposals because 
the manual work is painful/tedious/error prone? I don't see a problem 
having the rel_X_Y branch and tags/rel_X_Y_Z "branched" from rel_X_Y.  
<- Speaking to Jason's comments.

It should be easier to make release tarballs. Though, I'm sure it's 
never been as easy as it is today.

I think a step towards 100% automated would be that each and every patch 
should be required to have release note(s) added to the release notes 
adoc tree (docs/RELEASE_NOTES_NEXT). As well as edits to the 
documentation proper (if applicable) (docs/modules/*).

The "Release-notes" git tag could check the box if the commit is 
sufficiently small.

But I might be (getting away)/detracting from the topic of the thread.

-Blake-
Conducting Magic
Will consume any data format
MOBIUS

On 2/26/2024 10:00 AM, Jane Sandberg via Evergreen-dev wrote:
> 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
>
>
> _______________________________________________
> Evergreen-dev mailing list
> Evergreen-dev at list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/evergreen-dev/attachments/20240226/a043d279/attachment.htm>