Patch Set 2: > > > Maybe this patch should include the LIBVERSION bump, and making a > > > semantic release with signed tag needs to happen after the merge? > > It contradicts recommendations from > https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html#Updating-version-info
I don't see it, which part contradicts? > It doesn't mean it's completely bad but at least we should remember > to not update it again if it was updated already since the last > release. Yes, if we do it this way, each code change does a LIBVERSION bump, and such bump must no longer be part of the release process. > Also, updating "current" component of libversion means that we'll > have to update the filenames and metadata in debian/ as well which > is not yet covered by release automation so it has to be done > manually. Having to adjust the debian package names is a really cumbersome part of this. I wish we could do this automatically from interpreting LIBVERSION somehow..... I guess worst is the 'Conflicts' part (BTW, is it really necessary to conflict with earlier LIBVERSIONs?). As it is now, a software change breaking API/ABI also needs, besides the LIBVERSION bump, some "weird" debian packaging details committed alongside with it, and every developer has to know what's going on there to do it correctly (i.e. we'll have numerous -1 by the release manager until it's gotten right). -- To view, visit https://gerrit.osmocom.org/4317 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ifeb201d9006eec275a46708007ff342cdfc14e45 Gerrit-PatchSet: 2 Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Owner: dexter <pma...@sysmocom.de> Gerrit-Reviewer: Harald Welte <lafo...@gnumonks.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Max <msur...@sysmocom.de> Gerrit-Reviewer: Neels Hofmeyr <nhofm...@sysmocom.de> Gerrit-HasComments: No
