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

[Nate B. <n0...@n0...>]

* On 2025 06 Apr 13:04 -0500, George Baltz wrote:
> 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.

Hi George.

Thanks for looking through the list.  I've been going through it a bit
and have assigned some to myself that interest me.

I invite anyone who chooses to work on an issue to assign themself to
it.  Doing so doesn't set your name in stone, it is just merely an alert
to others browsing the list that someone has taken an interest in that
particular issue.  Also, if an issue is of interest and someone shows as
assigned, contact that person and collaborate!

> > 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.

Would it help to have a feature branch that your work can be pushed to
that could also track master?  Would that assist in parallel development
and perhaps shorten the time from where we are now to 5.0?

> > 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.

Thanks!

> > 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.

I'm intrigued.

> > 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.

Before we go any further, I'll explain what I see as my role in the
project.

First, I joined the project in early 2001.  While I have contributed
code in the past I am not nor will I ever be the lead developer.  I'm
the old guy that was here and took on the admin role on SourceForge when
Stephane stepped away and Set up the initial project on GitHub.  I've
done work wrangling with the build system and documentation.

Second, I also don't have much of a vision for Hamlib except for the
project to be accessible and to help keep the project active and viable
as best I can.  APIs change over time and I think all of the projects
that use Hamlib understand and are accepting of that so long as changes
are communicated well in advance.  Also, advancing the major number,
i.e. 4.x.x to 5.x.x, and so on, communicates that change.

Third, in light of the above, I see my role as being a facilitator for
those that write the actual Hamlib code.  Unlike Mike and many others, I
lack the experience and knowledge to engage in a discussion such as that
in issue 1445, though I find it fascinating.  As a project, Hamlib is
nearing its 25th anniversary--quite a milestone!  Along the way best
practices have changed and Hamlib should change to match and I defer to
those with the knowledge to lead that effort.

My pledge to the project is to merge pull requests and patches and make
sure that all contributors get credit for commits.  I'll also do what I
can to answer questions here and in our forums though everyone is
welcome to chime in.  It's not too likely that I'll get deeply involved
in technical discussions as I'll leave that to those with a better
vision of how Hamlib should be interested.  My inbox is always open.

I will continue to do releases when we determine the code is ready.

73, Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819