[Nut-upsdev] [networkupstools/nut] Project Release Cycle Plan Needed (Issue #1769)

[Jim Klimov]

Hello,

  Good question - I hoped to deal them out twice a year or so, but it
(toxically, in hindsight) stumbled on trying to adddress a few bugs
reported in 2.8.0 to deliver fixes as 2.8.1 :\

  I've dealt with projects that port stuff to a release/stable branch, and
at least for a small team like ours it is a much more difficult
endeavour/overhead than trying to keep "master" clean enough that after
almost any merged PR an end-user delivery can be made (so the complexity of
variable-quality code lives on feature branches that are merged when
perfect^H^H^H^H^H^H^H good enough).

  And for people who do actually follow the suggestion to try building NUT
from github because their distro is a year behind our latest release (and
ship one 6-7 years old instead) and lacks stuff fixed after 2.7.4 or even
2.8.0, it usually "just works" so the model is viable. Sometimes new corner
cases are uncovered and new bugs to fix are recognized.

Jim

On Wed, Jan 4, 2023, 19:05 biergaizi <notifications at github.com> wrote:

> First, apologize for the non-technical nature of this issue report. But I
> believe resolving this issue is crucial to downstream users given its
> importance. It's also worth reposting this issue to the mailing list for
> discussion.
>
> Last week, I've received yet another user E-mail inquiry on the lack of
> support of newer UPS2000 devices in my driver. The support was in fact
> already added by me back in Jul 3, 2022 - now 5 months has passed. I
> realized that it would be completely impractical if users have to wait for
> more than one year for a trivial 1-line code change - and the downstream
> distros would only delay the release further to 1.5 years - But this is
> exactly the case given the current state of the project.
>
> This raises the question of the plan of future project release cycle.
>
> What can we do in the future so that a user doesn't need to wait for a
> year for new device supports? Some possible plans:
>
>    1.
>
>    Mainline/Stable Model - The stable branch only carries bugfixes, new
>    Device IDs, and other trivial changes, possibly cherry-picked from the
>    development board. They're released as frequently as necessary, and due to
>    the lack of breaking change, downstream distros can also upgrade the
>    packages as soon as possible, without the long Debian-style unstable to
>    stable transition.
>    2.
>
>    Fixed release cycle - No matter how many milestones are reached, use
>    mandatory release schedule of once or twice a year, so support for new
>    devices and fixes won't be postponed indefinitely.
>    3.
>
>    Other plans?
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/networkupstools/nut/issues/1769>, or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAMPTFE2WPKK5BDTIX44AFTWQW3YDANCNFSM6AAAAAATRCDW3I>
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: <networkupstools/nut/issues/1769 at github.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20230104/2d9d2890/attachment.htm>