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/.

Neels Hofmeyr nhofmeyr at sysmocom.de
Mon Jan 21 13:18:56 UTC 2019


> > > 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.

I wish C had enum types with explicit size :/

IMO let's revert back to uint8_t and put the enum type in the API doc.

~N

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190121/8662daeb/attachment.bin>


More information about the OpenBSC mailing list