<div dir="ltr"><div><div>Hi Vadim, Harald,<br><br></div>I wanted to speak up and second the need to fix the USSD system, as Vadim notes it's actually just broken at the moment and doesn't meet the standard. A student in my lab (Rowan, cc'd) recently had to extend it to be able to interface with ussd_airflow, I believe building off of earlier fairwaves patches. We'd also like to be able to upstream those fixes to the community, but it seems that Harald's legacy support issue is the big hangup? Wouldn't it be easier to put related library versions into the changelog or something similar? Git submodules for instance allow you to specify a specific submodule hash and a mechanism like that could free up the interface development. <br><br></div>Just some thoughts. Thanks to everyone for bringing this issue up. <br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 13, 2018 at 3:00 PM, Harald Welte <span dir="ltr"><<a href="mailto:laforge@gnumonks.org" target="_blank">laforge@gnumonks.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Vadim,<br>
<br>
I'm sorry to respond to your elaborate mail in a very short way:<br>
<br>
We do not want to break building old versions of OsmoNITB & Co<br>
with new library versions. Every time we do this, we are creating<br>
problems to our users. We have done this several times in the<br>
past, and it's always a pain to handle.<br>
<br>
Let's assume anyone wants to build an old OsmoNITB version, for example<br>
in order to test for a regression (e.g. using 'git bisect'). How<br>
would you do this, if for every version you want to test, you need<br>
also *all* the matching libosmo* of that time. To make things worse,<br>
you don't even know which of the versions you need to use, making<br>
it impossible to hunt down when a regression was introduced in an effective<br>
way.<br>
<br>
It would be really nice to have some automatic jenkins build jobs that<br>
actually test at least building old code (e.g. openbsc.git) against<br>
current 'master' libraries to avoid accidents, and to even clean up some<br>
of the incompatibilities we may have introduced since, if possible.<br>
<br>
It's bad enough if we break this by accident. It's much worse if we<br>
do it knowingly.<br>
<br>
So whatever we do, we have to try our best to keep old APIs stable<br>
or backwards-compatible. In most cases, the old API would simply<br>
be a compatibility wrapper around the new API. So there's one<br>
implementation of a given functionality, but the new users use it<br>
directly, while the old users go through a compatibility wrapper.<br>
<br>
I don't have the details of the USSD code in my head, but I'd be surprised<br>
if it wouldn't be possible to simply wrap the new API behind an old<br>
API compat wrapper? If you encounter any specific problems, feel<br>
free to discuss ways how we can do this.<br>
<br>
Regards,<br>
Harald<br>
<span class="HOEnZb"><font color="#888888">--<br>
- Harald Welte <<a href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a>> <a href="http://laforge.gnumonks.org/" rel="noreferrer" target="_blank">http://laforge.gnumonks.org/</a><br>
==============================<wbr>==============================<wbr>================<br>
"Privacy in residential applications is a desirable marketing option."<br>
(ETSI EN 300 175-7 Ch. A6)<br>
</font></span></blockquote></div><br></div>