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

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-upsuser/attachments/20230104/2d9d2890/attachment.htm>

My thoughts are:

  we have an infinite number of version numbers

  it makes sense to, roughly every 6 months to a year, release 2.N+1.0 with
  whatever has accumulated after a several-week call for testing, even
  if it's not exciting.

  2.N.1 etc. can happen if there's something serious and othewise not.
  
So I see us as heading to 2.9.0 over the next few months but not
urgently.  I'm guessing Jim sees it similarly.



as for maintaining stable branches, that's work.  In another project I
maintain, I choose not to.  I don't want to do work for people that want
LTS -- they can do that work or pay for it.  (I find that the LTS world
tends to expect others to accomodate their desire for software that is
both old at new at the same time and I'm cranky about that, especially
for non-Free distributions.)