osmo-pcu, osmo-bts, osmo-bsc releases with PCUIF 12
Dear mailing list, I'm looking into releasing a new osmo-pcu version to finish up OS#6198, and to have a release with the fix for OS#6191. Apparently that fix requires a new PCUIF version. And osmo-pcu master now has a check that requires the *exact* PCUIF version: https://cgit.osmocom.org/osmo-pcu/commit/?id=46140948d9800bca6a7b4299f08b25e... pcu_i1_if.cpp: } else if (info_ind->version != PCU_IF_VERSION) { fprintf(stderr, "PCU interface version number of BTS/BSC (%u) is different (%u).\nPlease use a BTS/BSC with a compatble interface!\n", info_ind->version, PCU_IF_VERSION); exit(-1); } So we will need to create releases of osmo-bts and osmo-bsc with the new PCUIF version as well. As this is a breaking change, I think we should bump the major version, and that in turn makes more sense with tagging current master instead of cherry picking a few patches. So I propose to do the following: * tag a new libosmocore patch release with the few patches required for osmo-pcu, osmo-bts and osmo-bsc master (see their TODO-RELEASE). * tag major releases of osmo-pcu, osmo-bts and osmo-bsc from their current master Does that make sense? Best regards, Oliver -- - Oliver Smith <osmith@sysmocom.de> https://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte
Hello Oliver,
So I propose to do the following: * tag a new libosmocore patch release with the few patches required for osmo-pcu, osmo-bts and osmo-bsc master (see their TODO-RELEASE). * tag major releases of osmo-pcu, osmo-bts and osmo-bsc from their current master
Does that make sense?
Yes, I think this makes sense. Unfortunately, when the PCUIF version number is incremented, this will automatically affect OsmoPCU, OsmoBTS and OsmoBSC equally. (The PCUIF version number has to be incremented when protocol details change, in particular when new struct members are added.) Best regards, Philipp -- Philipp Maier <pmaier@sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte
Hi Philipp and mailing list, in today's meeting with Pau, Vadim (and Harald who had to go before the decision; would also have been nice to have Philipp there, would probably have been good if I said so explicitly before it), we decided to do the following: * tag no libosmocore release * tag osmo-pcu from master, but revert the patch that requires a new libosmocore beforehand (new minor version) * tag osmo-bts with cherry picked PCUIF 12 patches (new patch version) * tag osmo-bsc with cherry picked PCUIF 12 patches (new patch version) It isn't perfect regarding semver but this solution was the most reasonable in our opinion. The patches are here: https://gerrit.osmocom.org/q/topic:pcuif12-releases On 11.12.23 15:11, Philipp Maier wrote:
Yes, I think this makes sense. Unfortunately, when the PCUIF version number is incremented, this will automatically affect OsmoPCU, OsmoBTS and OsmoBSC equally. (The PCUIF version number has to be incremented when protocol details change, in particular when new struct members are added.)
We also thought about how to make this more elegant in the future, and had the idea of using TLV instead. Created this issue for future reference: https://osmocom.org/issues/6303 Best regards, Oliver -- - Oliver Smith <osmith@sysmocom.de> https://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte
Hi, On 12/12/23 17:16, Oliver Smith wrote:
* tag osmo-pcu from master, but revert the patch that requires a new libosmocore beforehand (new minor version)
Note, this could be done because the only patch requiring new libosmocore was actually only moving an internal helper function from osmo-pcu to libosmocore, so it can really be postponed to a later osmo-pcu version. After the release is merged, the revert will be reverted, putting the patch in place again. This is done for the sake of having clearer git history instead of having a release ranch with several patches, which didn't make sense in this case imho. -- - Pau Espin Pedrol <pespin@sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte
participants (4)
-
Neels Hofmeyr -
Oliver Smith -
Pau Espin Pedrol -
Philipp Maier