[Hamlib-developer] Hamlib 5.0 roadmap, goals and schedule + API/ABI breakage?

[Mikael N. <mik...@fa...>]

Hello all Hamlib developers!

I'd like to raise a discussion here that originated from GeoBaltz's long-awaited work on some ABI changes to make Hamlib more stable by, for example, modifying some internal data structures to be accessed via pointers.

It seems Hamlib development is seeing a rush of activity now, which is definitely a good thing.

As background, I've been involved in Hamlib development (for a couple of years already) by mainly introducing and extending backends + adding the UDP rig state snapshots / spectrum data API + more recently working on the ARDC improvement project (still very much in progress).

However, I've never really been aware of what the Hamlib release process actually is:

a) What are the "development windows" (schedule)?
b) When does release stabilization occur (when to stop accepting new proposals/features to a release)?
c) Where does Hamlib gather the roadmap for a particular release?

Regarding the roadmap, we have this release goals issue for 5.0: https://github.com/Hamlib/Hamlib/issues/1773 - but the discussion seems rather open-ended (+ issue is open), suggesting the release goals are not yet fixed.

There's also this list of issues tagged for 5.0 milestone: https://github.com/Hamlib/Hamlib/issues?q=is%3Aissue%20state%3Aopen%20milestone%3A5.0

Apart from those, the only documentation related to Hamlib releases I know of is simply the technical instructions for a release: https://github.com/Hamlib/Hamlib/blob/master/README.release

My main questions here are:

1. What's the status of the current master branch?
2. Is "master" supposed to be the development branch for 5.0 where we can still make API and ABI changes?
3. Do we have any target date for 5.0 in the **very near future** or can we keep the development window open maybe for at least a couple of months more until stabilization begins?

Hamlib 4.7 (the latest stable release) was only recently branched, so I'm assuming 5.0 development is still going on in master and we can still accept larger changes, even ones that break API / ABI if there is a good reason for that.

More background on the discussion:

The underlying reason for this discussion is that I'd really like to go forward with some additional API changes, specifically regarding device state in structs `rig_state`, `rot_state` and `amp_state`: currently these data structures are meant to be state internal to Hamlib, but many apps still access them directly, making it difficult to add new features or simply to make changes in these internal data structures (even in minor Hamlib releases) without breaking apps. Accidental ABI breakage has happened in the 4.x releases a couple of times with bugfix releases needed to fix them.

Making device state structs closed for direct access would mean that apps linking to Hamlib would need some targeted changes, e.g. using accessor functions or something similar to access the rig state when needed. I'm happy to share a more detailed plan in a GitHub issue + link it here later. This simply serves as an example of a change that would benefit from the API/ABI breakage that the new major version 5.0 allows.

In any case, even with the current ABI changes, the way forward seems to be that Hamlib 4.x and 5.x should be able to co-exist on a system (with proper versioning for dynamically linked libraries), since they're not binary-compatible anymore. My question is more about API compatibility: can we introduce breaking changes? So far there have not been many - if any?

Happy to hear what the consensus regarding Hamlib release schedule and API/ABI breakage is.

73,
Mikael OH3BHX