Greg Troxel
2025-Apr-08 12:57 UTC
[Nut-upsuser] NUT testing for v2.8.3 (hopefully imminent)
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.)
Jim Klimov
2025-Apr-08 13:57 UTC
[Nut-upsuser] [Nut-upsdev] NUT testing for v2.8.3 (hopefully imminent)
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 < nut-upsdev at alioth-lists.debian.net> 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 > Nut-upsdev at alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20250408/d8811c90/attachment.htm>