Hi, Harald,
I'm surprised to read this because I'm quite sure that you suggested breaking the API/ABI and increasing the library number yourself, and Vadim worked under the assumption that this is the suggested way to go.
On Sun, Jan 14, 2018 at 8:00 AM, Harald Welte laforge@gnumonks.org wrote:
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.
I personally believe that switching all libraries versions is the only right way to do in this situation because there are quite a lot of synchronized changes in both OsmoNITB and the underlying libraries. And specifically with hunting a regression example I would want to use a version of all the code in the exact state as it was before.
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.
I thought that library versions serve exactly this purpose - to know which version to build against?
Another way is something similar to what we've done in osmo-combo repo which allows you to specify specific commits in each sub-module to build against.
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'll let Vadim comment here but from what I remember, the old implementation is broken enough to make it difficult to maintain. I would rather focus on making sure the new API is good enough and we don't need to break things again in the foreseeable future.