Hi Max,
On Sat, Jan 19, 2019 at 04:56:43PM +0100, Max wrote:
19.01.19 00:24, Harald Welte пишет:
I've been looking at tagging new versions of
our libraries. I know Pau
in the past already used the abi-{dumper,tracer,...} toolkit, but I couldn't
find any instructions about it, nor has it been automatized it seems.
Maybe we could integrate it into 'make release' helper of libosmocore?
I don't see how that would work. You have to analyze *befoer* you do 'make
release'.
Instead, the plan is to simply run the job to generate the reports by a
cronjob every night, so that we have daily up-to-date reports of how
'current' differs from the last tagged version of
each library.
gsm0808_cause_name() changes the size of the argumetn from uint8_t to an
'int' that may be 32/64bit in size :( That breaks ABI, so we need to
bump soversion, or revert that change. As the gsup changes require a
version bump anyway, we should be fine.
In general, is there particular reason why we wouldn't want to bump
soversion when making new release? Unless it's a minor bugfix release of
course but so far we haven't bothered with those AFAIK.
Compatibility. We don't want to force people to rebuild all their
binaries just because somebody thought an enum was better than an
uint8_t as a function argument.
Sure, if there are important reasons to break ABI, do it. But don't do
it without a good reason.
gsm0808_create_lcls_conn_ctrl() has changed its argument type. Are we
sure there were no users of the function?
The only user I know of is OsmoBSC v1.3.0 which is part of several
repositories according to
https://repology.org/metapackage/osmo-bsc/versions
- shall we change the function name or bumping soversion will take care of
ABI incompatibility?
The problem here is not ABI compatibility, but API compatibility. Sure,
we can (and have to) bump the LIBVERSION/soversion. But then if you
want to build the old application (OsmoBSC v1.3.0 in your example)
against a new libosmocore it will fail. This is absolutely
unacceptable.
However, I cannot find any reference to gsm0808_create_lcls_conn_ctrl()
in osmo-bsc, neither in 1.3.0 nor in master - nor in the entire commit
log. I guess we were really lucky this time.
But still, I don't get all this "changing function signatures for no real
gain" game.
The old signature accepted pointers to the structure, and you had to
change it so the structures are passed on the stack. Where's the gain
in that? You camn do it one way or another. Why even only risk breaking
some unknown 3rd party program out there for no apparent benefit at all?
I'm confused by this: I thought that API breakage
is taken care by new
release version while ABI breakage is handle with new libversion?
API breakage is never "taken care of". We cannot break APIs, as a general
rule. Old applications should always work if recompiled against new
libraries. There are exceptions in situations where e.g. a symbol was
accidentially exported which was only meant to be used inside the
library. Then it's fine to remove it. But changing the signature of a
function *after* it has been part of a tagged version is *not*
acceptable.
Let me know if I should make a patch which will covert
ABI breakage into new
API by adding gsm0808_create_lcls_conn_ctrl2() for example.
If at all, I would simply revert the change. But it seems we can do
without.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)