<div dir="ltr">Hi,<br><div><br>On Mon, Feb 26, 2024 at 11:02 AM Jane Sandberg via Eg-newdevs <<a href="mailto:eg-newdevs@list.evergreen-ils.org">eg-newdevs@list.evergreen-ils.org</a>> wrote:<br>> My proposal would be to make all needed changes to the release series branch, </div><div>> and then create the tag branch directly from the release series branch when all </div><div>> these steps are done.  So, at the time of release, rel_3_12 and tags/rel_3_12_2 </div><div>> would be identical, before rel_3_12 starts to accumulate bug fixes for the next release.</div><div><br></div><div>I'm overall in support of the proposal.<br></div><div><br></div><div>If we move away from tag branches, I strongly advocate for using Git tags instead to represent the full release (and to enforce some discipline on us to apply a new tag if we discover that a release was a brown bag). We do this for OpenSRF, and Koha does it successfully as well.<br></div><div><br></div><div>One thing that I suggest is that we also consider dropping ChangeLog files outright, or if somebody is still using them from the tarballs, to generate just for the tarball. The release notes are what gets actually read by humans (and it would be easy to symlink from the release notes to ChangeLog if really needed). However, if anybody is actually reading (or possibly more likely, parsing the ChangeLog files) in its current form, please speak up.<br></div><div><br></div><div>Here's a piece that advocates against what we're currently doing to generate ChangeLog <a href="https://keepachangelog.com/en/0.3.0/">https://keepachangelog.com/en/0.3.0/</a></div><div><br>> It would eliminate any errors that could arise through</div><div>> differences in the release series branch and the release </div><div>> tag branch (e.g. not forward-porting the upgrade script to rel_3_12)</div><div><br></div><div>But note that we'll still need to do some forward-porting, but from series branches up to main.<br></div><div><br></div><div>> Having these things in the release series branch may cause some kind of</div><div>>  problem that I'm not familiar with.<br></div><div><br></div><div>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></div><div><br></div><div>Regards,</div><div><br></div><div>Galen<br></div><div>--<br>Galen Charlton<br>Implementation and IT Manager<br>Equinox Open Library Initiative<br>gmc@equinoxOLI.org<br><a href="https://www.equinoxOLI.org">https://www.equinoxOLI.org</a><br>phone: 877-OPEN-ILS (673-6457)<br>direct: 770-709-5581</div></div>