Re: [Hamlib-developer] Yaesu FTX-1--target for 4.7.0?

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

* On 2025 20 Jun 02:49 -0500, Mikael Nousiainen wrote:
> Hi folks!
> 
> There is some good planning here, great to see Hamlib going forward!

Trying something different.  🤣

> I'm trying to release some (long overdue) amplifier API extensions +
> backends during the summer, so I'd optimally like to get them to 5.0 +
> have some feedback. Stay tuned for a bit larger PR (once I get the
> Expert AMP backend fully tested).

+1
 
> We're (me and another developer from OH land) also aiming to get a
> larger Hamlib development project going after the summer (likely in
> September if all goes well) where we'd create a Hamlib backend testing
> framework (fully complementing the pytest stuff, which is on a higher
> level) + a lot of work to support network/SDR-based rigs. Let's see if
> we get the full support so we can spend the time required for it. We
> will release more info on this project as soon as we can! As a backup
> (even if the project didn't get all the support we need), we'll try to
> craft and release plans / APIs for future improvements we've had in
> mind. This is all 5.0 or 5.x work, of course.

+1

> Some questions about releases/schedule:
> 
> - Do you have any timeline in mind for a 5.0 release? Early next year? "When it is ready"?

Yes to the latter, and early next year would be an ideal target, but not
a hard one.  I don't know how popular Ubuntu is in the ham radio world
any more but some downstream distros do base on it and 26.04 should be
an LTS.  In this regard, having a made a couple of 4.7 branch releases
for stabilization and bug fixes is more important.

> - Do you see any 4.x releases preparing for the larger changes before it?

Yes, I'd like to see us get 4.7.0 released in three to four months time.
That should include some things identified in this thread as well as
FTX-1 support with at least the basics working.  As there is a report
that it works by selecting FTDX-10 in other software, this *should* be
fairly straight forward.  This gives plenty of time for 4.7.x to "settle
in" before 26.04 LTS.

When we're satisfied that we're close enough for 4.7, I'll create its
branch and all future 4.7 work will occur there and master will be
targeted toward 5.0.  This means 4.7.x would be the least series with
the present API/ABI and that 5.0 can make changes as needed.

None of this is to imply that our release schedule is governed by any
one distribution.  I just tend to keep an eye on these sorts of things
and realize there is a benefit to downstream when we keep those
schedules in mind.

> Also, please see my additional comments below.

I have some comments inline and at the bottom.

> On Fri, Jun 20, 2025, at 02:41, Nate Bargmann wrote:
> > Good list, George.
> >
> > * On 2025 19 Jun 14:04 -0500, George Baltz wrote:
> >> I do have a couple of things I would like to see in 5.0, and I've been doing
> >> some reading and doodling about them; nothing concrete yet, but here's my
> >> blue-sky ideas:
> >> 
> >> 1. Update the requirements for building/running/developing with Hamlib.
> >> 
> >>  * ANSI C is 35 years old - no need to support K&R C anymore.  I'd like
> >>    to see -std=c17 at least, but -std=c11 would still be better than c89.
> >
> > I think that should probably a 5.0.0 target.  C11 would likely be
> > safest, even though these days C17 should be supported, though likely
> > only really well on distros less than five years old, I would guess.
> >
> > I'm not sure what C standard MinGW/MSYS supports.
> 
> Fully agree at least with C11. We need more modern features in the code.

According to GNU, current GCC supports up to C23:

https://gcc.gnu.org/onlinedocs/gcc/Standards.html

From that page I read that C17 is a set of corrections to C11 so as
there is sufficient compiler support, then it seems like the rest of the
tooling is in question.  I've not looked to determine if autoconf or the
external archive have macros enforcing a minimum C version.

> >> Whew!  Writing that tells me I might have bitten off more than anyone can
> >> chew. Prioritize away!
> >
> > This is exactly why I want there to be no more than two or three
> > priority items per developer for each release.  It frees up the mind
> > from feeling overwhelmed and trying to do everything at once.  Over the
> > past five years I observed Mike seemingly swamping himself in just this
> > manner and we had much too long time elapse from the last 4.5.x release
> > to 4.6.  Of course that time included his ALS fight so that likely was a
> > huge factor as well.
> 
> +1 -> more coordinated/targeted fixes by release will help a lot!

I've been thinking about where to place a release goals document.  It
could be a thread here or a new document on the Wiki.  Thoughts?

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