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/.
Alexander Chemeris Alexander.Chemeris at fairwaves.coHi, 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 at 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. -- Regards, Alexander Chemeris. CTO/Founder, Fairwaves, Inc. Skype: Alexander.Chemeris Mobile: +1(424)400-7626 https://fairwaves.co Subscribe to Fairwaves news: http://eepurl.com/baL_pf