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