Re: [Hamlib-developer] 4.6.3 and 4.7.0 releases plan

[George B. <geo...@gm...>]

On 4/5/25 5:11 PM, Nate Bargmann wrote:
> Hi all.
>
> Over the past several days I've been looking over the issue tracker on
> GitHub and doing a little bit of triage that Mike was unable to get to.
I also spent some time going through the issues, and picked out a couple 
to work on.  There are also some duplicates, and some that might be 
complete except for verification.
> I know Mike had a vision of a future release timeline.  It's not set in
> stone so I'm not suggesting that the project hold itself rigidly to it.
> For example, he envisioned 5.0 by late 2026.  As I recall, bumping the
> major version is only necessary if the C ABI changes to such an extent
> that recompilation of client programs is necessary, so, for now, I don't
> foresee 5.0 being imminent.
Good.  The ones that I saw that could benefit from a 5.0 are the rig 
structure changes (1445, 1420, 536 and 487); see my comments in 1445.   
None of them will be ready soon.
> What I would like to do is ask that everyone take a look at the issue
> tracker:
>
> https://github.com/Hamlib/Hamlib/issues
>
> and look for something that you can help with.  Some are getting to be
> quite old with the oldest at almost five years.  Some require some
> testing with certain hardware to see if an issue still exists.  It's
> impossible for anyone to have all of the hardware Hamlib supports so the
> project has always depended on help from those with hardware.  To that
> end I would like to see the number of issues reduced by month's end, if
> possible.
OK.  Will try to bring the numbers down.
> This leads to my plan for the next release.  I would like to roll up the
> current master branch into a 4.6.3 release by the end of April.  As all
> of the commits since 4.6.2 appear to be fixes and not new features,
> please limit Pull Requests (PRs) to fixes including closing issues.
> Upon release, 4.6.3 will be dedicated to the memory of Mike.
>
> After the next release, master will be open to new features and be
> planned as a 4.7.0 release.  I've been a bit lax in adding the '.0' to
> the initial minor release in a series and I think that has resulted in
> some confusion over the years.  Hopefully 4.7.0 can be released in a few
> months.
Great.  If we decide to work toward a 5.0 release, I think I can make it 
possible to build a 4.7 client that will be API-compatible with both 
pre-4.7 and 5.0 libraries.
>
> At one time I proposed to have a release cadence of late winter
> and late summer to stay ahead of the Ubuntu release cycle.  I'm not sure
> if this is still a reasonable release strategy as I'm unsure if Ubuntu
> is still the amateur radio favorite it once was.  It's likely best that
> we make releases when it is the best timing for this project, i.e. when
> it's ready.
Definitely.  I don't see a 4.7 coming together before the end of the year.
>
> Thoughts?
>
> 73, Nate
>
-- 

73

n3gb