I more or less agree that the release is due (or overdue, considering an earlier hope for half-a-year cadence).
Regression-wise, there were a few complaints specific to 2.8.0 changes vs. 2.7.4 which I think have got addressed, though not quickly sure if all of them were - which became a large part of the delay: * make USB report "fixup" optional by device configurations (disable_fix_report_desc: not all devices with same IDs are equivalently buggy) - https://github.com/networkupstools/nut/issues/1566 / https://github.com/networkupstools/nut/pull/1575; * some discussions of mis-processing of generally applied USB LogMin/LogMax fixups for invalid encoding happened, not sure OTOH if solutions (e.g. an option to not do it) were proposed in the end... I think it was the https://github.com/networkupstools/nut/issues/1512 (at least began as a regression discussion) which is not closed yet, in particular; * a "conveniently sorted" array introduced a bug, for that one driver the original entry order was there for a reason - https://github.com/networkupstools/nut/issues/1427; * a driver that did not start unless debugged - https://github.com/networkupstools/nut/issues/1455; * battery.voltage and battery.charge estimation in Qx drivers was not always useful/meaningful - in testing https://github.com/networkupstools/nut/pull/1652/ / https://github.com/networkupstools/nut/issues/1279; * not sure OTOH if usbhid-ups crash upon reconnect was a regression after 2.7.4 - fixed in https://github.com/networkupstools/nut/pull/1632 I've recently cleaned up https://github.com/networkupstools/nut/milestone/8 (goals of 2.8.1), delaying some 40 issues and PRs to subsequent releases and keeping the few which I want to take a look at actually fixing before cutting it (or also delaying). Recent X-mas/NewYear burst of activity for packaging recipes, upsmon complaints, systemd and several other subjects was part of that purge: delaying is not the only way to address the backlog :) Jim On Mon, Jan 9, 2023 at 5:17 PM Greg Troxel <[email protected]> wrote: > It seems we have crossed the threshold where regular people are better > off with git master vs the most recent formal release. Particularly > because packaging systems package actual releases, that leads to a > release being overdue. > > There are infinite things to improve, and 536 open issues. My view is > that a release needs to only have some degree of improvement (which git > master clearly does) and not have significant regressions. > > I therefore wonder about: > - let's try to shake out regressions and bugs in code new to the release > - defer fixes that aren't regressions > - get 2.8.1 out > > and then continue hacking. > > From the packager viewpoint, it takes 10 minutes to update to a release, > plus time to adapt to changes. So as long as releases are not more than > every few months on average, there's no issue. > > (There's a related issue about asking users filing bugs to retest with > the latest release, which argues for having that release be fairly > recent.) > > (There is windows binaries, but I don't see that as a regression and I > don't see anyone actively working on it.) > > What's in the regression category, once python searching is updated? > > Greg > > _______________________________________________ > 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
