[Nut-upsdev] NUT v2.8.0 unveiled, just a few years (too many) in the making

Jim Klimov jimklimov+nut at gmail.com
Tue Apr 26 22:59:19 BST 2022


Hello, fellow NUTs!

After a long and windy trip since the last official release v2.7.4 half a
dozen years ago, we the community, contributors and maintainers are proud
to announce at last the general availability of NUT v2.8.0!

As always, the new release includes numerous new drivers, sub-drivers,
protocols and bug-fixes, with many companies and individuals chipping in
with contributions of code.Thanks to everyone involved in making this
happen, inspiring the changes, and providing the open-source friendly
infrastructure.

This release also culminates a significant effort in improvements of NUT QA
and CI, and as a result -- in codebase quality and portability across a
decade or two of recent platforms, third-party tools and other
dependencies. As a side effect, public API (in headers and libraries) has
changed a bit, hence a new semantic "minor" number is claimed for this
major body of work.

During this time, the https://networkupstools.org/ web site has changed to
a rolling-release model to serve current information to match the evolving
codebase. There are now special Sub-sites for historic releases
<https://networkupstools.org/historic/index.html> to keep documentation
snapshots relevant for users of packages which are typically based on
official NUT releases.

We recognize that NUT is an important piece of infrastructure which gets
built into all sorts of devices, projects and operating systems -- some of
which the team never heard of until they pop up in a question, and others
we haven't heard of for years -- so we take a seriously omnivorous stance
towards covering many versions and implementations of compiler suites,
C/C++ revisions, make programs, shell and other scripted language
interpreters, OSes and CPUs, and other similar variables tamed with our new
NUT CI farm test matrix dynamically driven
<https://github.com/networkupstools/jenkins-dynamatrix> by currently
registered build agents and their declared capabilities.

Sections in the NEWS and UPGRADING files about changes since last release
are several pages long, so would not all be repeated here. A few important
highlights for distribution packagers and custom builders follow, however:

   - NUT now supports more i2c and modbus devices, as well as libusb-1.0
   support as an alternative to earlier libusb-0.1 (so new dependency-based
   categories of packages for drivers may be due);
   - NUT Python modules and scripts (e.g. NUT-Monitor variants) should work
   with python-2.7 and with python-3.x, so covering historic distro releases
   as well as new ones (and so *your* distro can deliver one or both,
   probably in several packages with different dependencies in the latter
   case);
   - NUT provides revised reference systemd and SMF service unit
   definitions, including support of drivers wrapped into individual service
   instances with varying dependencies based on different media required
   (networked stack, USB stack, etc.), and many daemons include -F option
   for running "in foreground" to avoid extra forking after one already done
   by a service framework - you may want to use those in your packaged
   deliverables;
   - NUT newly provides the "nut-driver-enumerator" script and service,
   which allows it to follow edition of ups.conf and dynamically
   define+(re)start and stop+undefine service instances for drivers - there
   are several ways it can be integrated for different use-cases;
   - there are several new configuration keywords and CLI options - so
   while new NUT builds should work with old configs and scripts, the opposite
   is not necessarily true (old binaries may reject configurations taking
   advantage of new features);
   - there are several new protocol keywords - but old and new NUT daemons
   (data server and clients) should be able to communicate both ways;
   - it is assumed that API/ABI changes may require third-party NUT clients
   (library consumers of libnutclient, libupsclient, libnutscan... -- their
   version info was bumped accordingly) to get rebuilt, in order to work with
   the new NUT release in a stable fashion;
   - the dummy-ups driver used in automated testing now processes *.dev
   filename patterns once and does not loop, like it still does for *.seq
   and other files (by default);
   - USB code is now more strict about logical minimum/maximum ranges for
   data reported from devices, and some devices were already found to make
   mistakes - so there is also a mechanism for turning a blind eye to known
   issues and fix-up such report descriptors to produce intended sane values;
   - new documentation page docs/config-prereqs.txt highlights packaged
   dependencies installable on a large range of platforms to build as much of
   NUT as possible (incidentally, ones NUT CI farm uses to test every
   iteration);
   - finally, we hope that NUT codebase might be able to cater for everyone
   "out of the box" (it also simplifies local builds from GitHub sources on
   any systems, for troubleshooting and checking pre-release enhancements): if
   you as a packager have to apply patches for your distribution, give it a
   thought -- whether they address a common issue best solved upstream once
   and behave similarly for everyone (and conversely, if your platform can do
   with existing solutions already tracked in the NUT version du-jour). PRs
   welcome! Or at least Wiki entries
   <https://github.com/networkupstools/nut/wiki/Links-to-distribution-packaging-recipes-and-repository-sections>
   to list all the distro efforts for cross-pollination :)

A lot of effort and several rounds of community testing have gone into
making sure that all these new features and bug-fixes and addressed
warnings did not break anything severely, but... things might happen.

Still, there is always room for improvement and many known efforts that did
not make it into this release got queued into the next. Likewise, there are
some open issues about device/model/firmware-specific behaviors that are
known but were not even addressed - we would always welcome help and PRs
from community members with devices, debugging/coding skills, and time to
spare.

In any case, we hope the next NUT releases will happen in a more manageable
cadence ;)

Managing power can be fun, but mis-managing power can be dangerous. While
we hope that new NUT release would not have fallout as spectacular and
dramatic as from a certain other power monitoring and management system
that failed 36 years ago today
<https://world-nuclear.org/information-library/safety-and-security/safety-of-plants/chernobyl-accident.aspx>,
please do take care with your electric experiments, and do secure your
installations!
On behalf of the Network UPS Tools team,
Jim Klimov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20220426/155d3ddf/attachment.htm>


More information about the Nut-upsdev mailing list