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 ([email protected]) 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 > [email protected]http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev > > > _______________________________________________ > Evergreen-dev mailing list > [email protected] > http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev >
_______________________________________________ Evergreen-dev mailing list [email protected] http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev
