[Eg-newdevs] [Evergreen-dev] Release branch proposal

[Jane Sandberg]

Thanks, Jason and Blake.


   - +1 to using git tags, rather than our "tag" branches.  I think they
   are well suited to and widely used for that purpose.
   - +100000000 to more automation of the release process.
   - I don't think these changes would matter too much if the process was
   fully automated (although I do think that using real version numbers,
   rather than Xs in the public-facing documentation would be an
   improvement).  It's more focused on now, when we lowly humans have to do
   these steps.


El lun, 26 feb 2024 a la(s) 12:03 p.m., Blake Graham-Henderson via
Evergreen-dev (evergreen-dev at list.evergreen-ils.org) escribió:

> 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 listEvergreen-dev at list.evergreen-ils.orghttp://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev
>
>
> _______________________________________________
> 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/eg-newdevs/attachments/20240226/66bb4558/attachment.htm>