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

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

* On 2025 03 May 13:19 -0500, Daniele Forsi wrote:
> Hello,
> 
> I'm also ok with a 4.6.3 now. I have 3 PRs in draft which are more
> suitable for 4.7 or later because they involve changes in the builds.

Ack.

> > Yes, I plan to create a 4.6.3 branch off master.  In the future I hope
> > to get back to having a branch such as "4.7"
> 
> creating a stable branch makes it easier for contributors to send pull
> requests to fix small bugs, being small, they are probably easy to
> cherry-pick in the development branch.

Agreed.  Cherry-picking can work the other way as well so long as the
file in master hasn't diverged too much from stable.  In that case a new
commit is likely needed.

> > This is probably an area that could be improved so I'm open to ideas on
> > how best to have PRs integrate into an existing stable branch and the
> > master development branch.
> 
> one possible workflow is to accept in the stable branch only fixes
> that improve stability (eg. parameter checking or error handling);
> changes to the documentation could also go in stable if they improve
> the life of downstream maintainers or users; changes related to
> firmwares probably need a decision on a case by case basis.

Agreed.  That has always been my intent.  The last few releases have
been somewhat chaotic and it didn't work, or rather it was too much
work, to work through what seemed to be a series of commits that
happened each time a file was saved and then a series of corrections and
such.  Better, IMO, is to edit, save, test, and then when mostly
satisfied commit.  Or, if the workflow of an editor demands a commit
each time a file is saved, then rebase to make a single or a couple of
commits.  As Seve, AI4QR, once quipped, "Rebase allows me to look like I
know what I'm doing," or something close to that!  Over time I came to
really appreciate that comment.

> What would be the name of the development branch? I have a slight
> preference for a fixed name such as devel or next (o something else)
> versus a numbered name, because it can create ambiguity until it's
> released (eg. if we had Hamlib-4.6.23 and Hamlib-4.7 it wouldn't be
> clear if 4.7 is stable or not)

The development branch has always been "master".  Admittedly, this got a
bit clouded over the past several months, at least since the 4.6
release.  The version string in 'configure.ac' is an indicator of the
next milestone target.  For example, it will remain "4.7~git" for a
while, at least until 4.7.0 is released and then it could advance to
"4.8~git" or "5.0~git" depending on the plan for incompatible C ABI
changes, i.e. if the ABI is not backward compatible then the major
number should be advanced, but the version string in master will always
have '~git' appended as in indicator that it is from the development
branch.

After the 4.6.3 branch is created, I will merge more substantial changes
into master such as new device families or new device models and some
other things that others have expressed an interest in contributing.
Some of these decisions as to what will be ported to a stable branch
will remain ad hoc to retain some level of flexibility.

Hope that helps.

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