[Nut-upsdev] [Nut-upsuser] NUT testing for v2.8.3 (hopefully imminent)

[Jim Klimov]

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-upsdev/attachments/20250408/d8811c90/attachment.htm>