<div dir="auto">Hello,<div dir="auto"><br></div><div dir="auto">  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 :\</div><div dir="auto"><br></div><div dir="auto">  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).</div><div dir="auto"><br></div><div dir="auto">  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.</div><div dir="auto"><br></div><div dir="auto">Jim</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 4, 2023, 19:05 biergaizi <<a href="mailto:notifications@github.com">notifications@github.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p></p>
<p dir="auto">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.</p>
<p dir="auto">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.</p>
<p dir="auto">This raises the question of the plan of future project release cycle.</p>
<p dir="auto">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:</p>
<ol dir="auto">
<li>
<p dir="auto">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.</p>
</li>
<li>
<p dir="auto">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.</p>
</li>
<li>
<p dir="auto">Other plans?</p>
</li>
</ol>

<p style="font-size:small;color:#666">—<br>Reply to this email directly, <a href="https://github.com/networkupstools/nut/issues/1769" target="_blank" rel="noreferrer">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AAMPTFE2WPKK5BDTIX44AFTWQW3YDANCNFSM6AAAAAATRCDW3I" target="_blank" rel="noreferrer">unsubscribe</a>.<br>You are receiving this because you are subscribed to this thread.<img src="https://github.com/notifications/beacon/AAMPTFGLDOREHWWUUJFIYGLWQW3YDA5CNFSM6AAAAAATRCDW3KWGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHFVD7EOA.gif" height="1" width="1" alt=""><span style="color:transparent;font-size:0;display:none;overflow:hidden;opacity:0;width:0;height:0;max-width:0;max-height:0">Message ID: <span><networkupstools/nut/issues/1769</span><span>@</span><span>github</span><span>.</span><span>com></span></span></p>
</blockquote></div>