[Eg-newdevs] [Evergreen-dev] Release branch proposal
Jane Sandberg
sandbergja at gmail.com
Mon Feb 26 15:34:43 EST 2024
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>
More information about the Eg-newdevs
mailing list