<div dir="ltr"><div>Sorry, that was one mishap layered onto another - the "v2.8.3-rc1" tag was supposed to point to the same commit as what I originally hoped was "v2.8.3"... but did not - instead initially pointed to what would land to `master` among its fixes for a cleaner release. Hopefully tags are correctly refined on GitHub repo now, at least.</div><div><br></div><div>Jim</div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Apr 8, 2025 at 2:58 PM Greg Troxel via Nut-upsdev <<a href="mailto:nut-upsdev@alioth-lists.debian.net">nut-upsdev@alioth-lists.debian.net</a>> wrote:<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 starting down the path of testing.<br>
<br>
<br>
There are commits in the rc tag that are not on master:<br>
<br>
$ git log --oneline ..v2.8.3-rc1<br>
3d286fb1b (tag: v2.8.3-rc1, jimklimov/pre-283-2) appveyor.yml: handle also FTY and fightwarn branches<br>
4e92275c1 .github/workflows/codeql.yml: handle also FTY and fightwarn branches<br>
504706d45 Makefile.am: nut-scanner does directly depend on clients after all<br>
051b49d9f Revert "Revert "NEWS.adoc, UPGRADING.adoc, docs/<a href="http://docinfo.xml.in" rel="noreferrer" target="_blank">docinfo.xml.in</a>: finalize text before NUT v2.8.3 release""<br>
70faea2af Revert "tools/gitlog2version.sh: bump NUT_VERSION_DEFAULT=2.8.3.1 for next development cycle"<br>
e1d399b5e include/Makefile.am: nut_version.h: propagate failure (if there ever is one) writing the temporary output<br>
a33fb1616 clients/Makefile.am: libupsclient-version.h: take a transactional approach to changing (or not) the file others depend on<br>
<br>
so all in all I find this far more confusing than it needs to be.<br>
<br>
<br>
<br>
As an aside about CM practices:<br>
<br>
I think when there's an RC, then it should just be on master, with the<br>
idea that other changes are not allowed until release. The current<br>
state is more confusing than necessary.<br>
<br>
Running 'git branch -a', there are 66. I realize there are probably<br>
reasons for some of them to exist, but there are no many that the<br>
noise makes it harder to understand the repository. I suggest<br>
removing most of them (or parking them in a private repo if it's<br>
really not ok to just remove them, but they don't have significant<br>
continuing value).<br>
<br>
There's no branch in the repo for the release. (I prefer releases<br>
from master with other commits banned, but if it's not that way it<br>
needs a release branch.)<br>
<br>
(I realize nut does not have release branches to be able to make micro<br>
releases, and I realize we could create one retrospectively if that<br>
turns out to be necessary. I'm ok with that as long as releases are<br>
from master.)<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Nut-upsdev mailing list<br>
<a href="mailto:Nut-upsdev@alioth-lists.debian.net" target="_blank">Nut-upsdev@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a><br>
</blockquote></div>