Nut upsdev - Apr 2025 - 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>

Jim Klimov <jimklimov+nut at gmail.com> writes:
> 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.
Thanks, looks ok now and restarting full testing.

I took v2.8.3-rc in git, bootstrapped autoconf, build, make check, make
dist, (on NetBSD 10) and then used that tarball as the source for
pkgsrc, built a package, installed it on machine with a Best Fortress
(NetBSD 9), rebooted, and both upsc and a program that uses the pyNUT
interface code seem fine.

So I see no problems.  (Of course, I always like there to be a multiday
interval from rc to release so I don't mean to hurry you.  Just that it
looks good  to me.)