<div dir="ltr"><div dir="ltr"><div>Thanks all for this discussion.  Since the discussion has calmed a bit, I'll try to summarize, and float an additional idea.</div><div><br></div><div>I've heard more or less consensus on the following:</div><div>* These are changes we could make in the 3.12 series, we wouldn't have to wait.</div><div>* More automation in this process would be great</div><div>* Removing Changelog generation from the process</div><div><br></div><div>Some more points where we should discuss further:</div><div>* Using git tags instead of tag branches (git tags seem popular, but for some it would be a supplement to our point release branches; for others, it would be a replacement)</div><div>* What version should be stamped while the release branch is between versions</div><div><br></div><div>I understand the concern about having a repo with 3.12.4 work but a 3.12.3 stamp.  I'm curious what you think about the opposite scenario:</div><div>* The release team releases 3.12.3</div><div>* As part of this process, after generating the tarballs, make_release queues things up for the next release by stamping 3.12.4</div><div>* We add new bugfixes to the repo.  The repo is stamped as 3.12.4, the commits we are adding to it will be in 3.12.4 (even if it's not the absolute final 3.12.4 release)</div><div>* When 3.12.4 is released, there is no need to restamp anything when preparing the tarball.  We set a rel_3_12_4 git tag at the appropriate commit in rel_3_12, and make_release subsequently re-stamps to prepare for 3.12.5.</div><div><br></div><div>Please let me know if I missed or misrepresented anything in the summary, and your further thoughts on the topics mentioned above.  And also, should we try to make a decision about this in the next developer meeting?</div><div><br></div><div>  -Jane</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El lun, 26 feb 2024 a la(s) 2:01 p.m., Mike Rylander (<a href="mailto:mrylander@gmail.com">mrylander@gmail.com</a>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I'm +1 to this proposal, especially in spirit (that is, automate more<br>
and reduce non-automated duplicate steps to a minimum)!<br>
<br>
One bit of soft push-back on a detail below...<br>
<br>
On Mon, Feb 26, 2024 at 3:42 PM Galen Charlton via Eg-newdevs<br>
<<a href="mailto:eg-newdevs@list.evergreen-ils.org" target="_blank">eg-newdevs@list.evergreen-ils.org</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> On Mon, Feb 26, 2024 at 11:02 AM Jane Sandberg via Eg-newdevs <<a href="mailto:eg-newdevs@list.evergreen-ils.org" target="_blank">eg-newdevs@list.evergreen-ils.org</a>> wrote:<br>
> > My proposal would be to make all needed changes to the release series branch,<br>
> > and then create the tag branch directly from the release series branch when all<br>
> > these steps are done.  So, at the time of release, rel_3_12 and tags/rel_3_12_2<br>
> > would be identical, before rel_3_12 starts to accumulate bug fixes for the next release.<br>
><br>
<br>
[snip]<br>
<br>
><br>
> > Having these things in the release series branch may cause some kind of<br>
> >  problem that I'm not familiar with.<br>
><br>
> I think the main thing will be ensuring that any tooling that updates the version numbers is rock solid. We might also consider, immediately after doing a release, doing a commit that updates the version numbers again to clearly indicate that the series branch is back to a pre-next-version mode.<br>
><br>
<br>
IMO, for humans, having a version number stamped on something that is<br>
actually that-version-plus-more is asking for trouble.<br>
<br>
So, I think we should keep the release "tag" branches because of that,<br>
as a form of repo hygene.  Having a pair of interstitial commits each<br>
month (ha!) to mark the release, then tag that commit /as/ the<br>
release, and then a commit to /un/mark the release version number in<br>
the code seems messier on balance than having a branch with a single<br>
version-number-update commit.  Bonus: the branch graph will also show<br>
the cul de sac that is each release version.<br>
<br>
I realize that the version number is the only thing identified in the<br>
process /today/ that we'd (well, definitely "I'd") want to roll back<br>
after tagging, but as soon as we have two things (or more) then we'd<br>
be introducing blocking after-release checklist items that are needed<br>
before we can open the repo up for cherry picks and merges.  A release<br>
branch lets those continue without a general workflow pause for new,<br>
additional cleanup, and down the road if we need more than the version<br>
update to be recorded for a release then we have time and space in the<br>
release branch.<br>
<br>
A parallel to the release versioning (and I think it was mentioned in<br>
the thread before) would be to update the series-level version<br>
stamping as soon as the series branch is created.  This has the<br>
benefit of priming the release branches for simpler updates AND<br>
automated cross-checks that you're stamping a release for the intended<br>
branch -- does the series you're releasing from have a version number<br>
in the code that is a prefix of the release number you're building? --<br>
and makes "change the version number in the code" the first (and only,<br>
maybe, for release branches) commit you should see at the branch point<br>
from its parent, and creating that commit on the new branch should the<br>
first thing a committer should be doing when creating a branch in the<br>
main (not working) repo, for either a new series OR a new releases.<br>
"new branch? new version number!"<br>
<br>
We can still use true git tags against the tip commit on the release<br>
branch to create an immutable artifact in the repo and even work<br>
towards having make_release require (or create?) those true git tags,<br>
but a process cleanup and improvement now seems more attainable, or at<br>
least less disruptive, than changing our definition of "release-time<br>
git thing".<br>
<br>
Thanks!<br>
<br>
--Mike<br>
<br>
> Regards,<br>
><br>
> Galen<br>
> --<br>
> Galen Charlton<br>
> Implementation and IT Manager<br>
> Equinox Open Library Initiative<br>
> gmc@equinoxOLI.org<br>
> <a href="https://www.equinoxOLI.org" rel="noreferrer" target="_blank">https://www.equinoxOLI.org</a><br>
> phone: 877-OPEN-ILS (673-6457)<br>
> direct: 770-709-5581<br>
> _______________________________________________<br>
> Eg-newdevs mailing list<br>
> <a href="mailto:Eg-newdevs@list.evergreen-ils.org" target="_blank">Eg-newdevs@list.evergreen-ils.org</a><br>
> <a href="http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/eg-newdevs" rel="noreferrer" target="_blank">http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/eg-newdevs</a><br>
</blockquote></div>