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.orgHi Vadim,
I'm sorry to respond to your elaborate mail in a very short way:
We do not want to break building old versions of OsmoNITB & Co
with new library versions. Every time we do this, we are creating
problems to our users. We have done this several times in the
past, and it's always a pain to handle.
Let's assume anyone wants to build an old OsmoNITB version, for example
in order to test for a regression (e.g. using 'git bisect'). How
would you do this, if for every version you want to test, you need
also *all* the matching libosmo* of that time. To make things worse,
you don't even know which of the versions you need to use, making
it impossible to hunt down when a regression was introduced in an effective
way.
It would be really nice to have some automatic jenkins build jobs that
actually test at least building old code (e.g. openbsc.git) against
current 'master' libraries to avoid accidents, and to even clean up some
of the incompatibilities we may have introduced since, if possible.
It's bad enough if we break this by accident. It's much worse if we
do it knowingly.
So whatever we do, we have to try our best to keep old APIs stable
or backwards-compatible. In most cases, the old API would simply
be a compatibility wrapper around the new API. So there's one
implementation of a given functionality, but the new users use it
directly, while the old users go through a compatibility wrapper.
I don't have the details of the USSD code in my head, but I'd be surprised
if it wouldn't be possible to simply wrap the new API behind an old
API compat wrapper? If you encounter any specific problems, feel
free to discuss ways how we can do this.
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)