<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Jane,<br>
<br>
Thank you for the well-thought-out proposal.<br>
<br>
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.<br>
<br>
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.<br>
<br>
It should be easier to make release tarballs. Though, I'm sure it's
never been as easy as it is today.<br>
<br>
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/*).<br>
<br>
The "Release-notes" git tag could check the box if the commit is
sufficiently small.<br>
<br>
But I might be (getting away)/detracting from the topic of the
thread.<br>
<br>
<pre class="moz-signature" cols="72">-Blake-
Conducting Magic
Will consume any data format
MOBIUS</pre>
<div class="moz-cite-prefix">On 2/26/2024 10:00 AM, Jane Sandberg
via Evergreen-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAH++r7F9V-JtEYk9eJWB00PZH++0t+1rxqEaG5Z3HZJasLeWyQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">
<div>Hi all,</div>
<div><br>
</div>
<div>I'd like to propose a change to <a
href="https://wiki.evergreen-ils.org/doku.php?id=dev:release_process:evergreen:how_to_build"
target="_blank" moz-do-not-send="true">the release process</a>
(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).</div>
<div><br>
</div>
<div>These go into both:</div>
<div>
<ul>
<li>The database upgrade script (depending on the branch,
this can be found in commits called "Forward-port[...]"
or "Bumping version numbers, adding Upgrade
Script[...]")</li>
<li>The release notes</li>
<li>Untranslated strings that are bound to launchpad (in
commits called "Translation updates - newpot")</li>
</ul>
</div>
<div><br>
</div>
<div>These go only into the tag branch:</div>
<div>
<ul>
<li>Updates to translated strings from both launchpad and
PoEditor</li>
<li>Bumping the version string in
Open-ILS/src/perlmods/lib/OpenILS.pm</li>
<li>Bumping the version string in
Open-ILS/src/perlmods/lib/OpenILS/Application.pm</li>
<li>Putting an actual version (instead of 3.X.X) into
docs/modules/installation/pages/server_upgrade.adoc</li>
<li>The Changelog</li>
<li>An upgrade_log sql statement in 002.schema.config.sql.</li>
<li>Some XUL stuff, apparently.</li>
</ul>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>From my limited perspective, here are the pros:</div>
<div>
<ul>
<li>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)</li>
<li>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.</li>
<li><a
href="https://docs.evergreen-ils.org/docs/3.12/installation/server_upgrade.html#_upgrade_the_evergreen_code"
target="_blank" moz-do-not-send="true">Our public
documentation</a> would include the actual version
numbers and file names for the most recent release in a
series, rather than a bunch of Xs. </li>
<li>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).</li>
<li>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.</li>
</ul>
</div>
<div><br>
</div>
<div>Cons:</div>
<div>
<ul>
<li>Having these things in the release series branch may
cause some kind of problem that I'm not familiar with.</li>
<li>People may have tools that help them roll releases
that would need to be changed.</li>
</ul>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Thanks for considering!</div>
<div><br>
</div>
<div> -Jane</div>
<div><br>
</div>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Evergreen-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Evergreen-dev@list.evergreen-ils.org">Evergreen-dev@list.evergreen-ils.org</a>
<a class="moz-txt-link-freetext" href="http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev">http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>