Carl Laufer writes:
> If the upstream osmocom soversion is bumped, then all forks will eventually
> need to follow too. Because software packages will begin getting written
> for version 2, then those forks will need to update to be useful to those
> programs.
I think the real issue is what are
Hi guys,
FYI If the 2.x version of the package is installed, it will not be
automatically replaced by version 0.x, even if 0.x is newer and 2.x is older.
The APT package manager adheres to the semantic versioning scheme to identify
the newer version.
Best Regards,
Andrey
> On 27 Mar 2024, at
Hi Steve,
If the upstream osmocom soversion is bumped, then all forks will eventually
need to follow too. Because software packages will begin getting written
for version 2, then those forks will need to update to be useful to those
programs.
I believe the soversion should only be bumped when
Hi,
the reason why the version was bumped is because there are several
forks of rtl-sdr that used version 0.8 and beyond, without changing the
library name. Many people requested the release of a new version, and to
avoid colissions of the version number with those forks, the major
version was
To add to this here is a Twitter/X thread that the developer of SDR++ has
put out, regarding the issues he's seeing with this major version number
change.
https://twitter.com/ryzerth/status/1771016439681466697
Regards,
Carl
On Fri, Mar 22, 2024 at 3:19 PM Carl Laufer wrote:
> Hi, I just saw
