tagging new versions / problems

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Sat Jan 19 20:35:33 UTC 2019


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 at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



More information about the OpenBSC mailing list