Re: External USSD interface development

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