On Mon, 20 Mar 2023 at 07:55, zyx <z...@gmx.us> wrote: > My question is: why do you want to change it? What is that going to > fix? Is that just a personal reason? I'd rather stick with something > well-established [1], than changing such things only because I do not > like them.
First: the major change is decoupling the two versions. That is, if we keep the x.y.z form, we could potentially have a 2.0.0 library version and still a 1.0.0 SO version. About moving to a single digit versioning it's not about personal preferences but removing decision points and a possible ambiguity: an ABI versioning should really state that the ABI broke compared to the previous version: with a x.y.z SO versioning we have similar form versions that are loosely related and can be possibly misunderstood. If we just state that the SO versions should match library version each time the ABI breaks, that removes the need for a decision but doesn't solve the ambiguity. If you think about introducing an automation, it's true that it may slightly easier to do (pseudocode): if (currentABIDump != previousABIDump) soVersion = libVersion; Than doing: if (currentABIDump != previousABIDump) soVersion++; Because the latter requires arithmetic, and the former doesn't. The latter becomes easier to do if the SO versioning is a single digit. Concluding, just looking at your example inspecting /usr/lib64, anything that can't be enforced is just a recommendation, not a rule: in my opinion, the libraries that use a single number for SO versioning better understood the point of such versioning. So I ask you: how comfortable you are with a SO version in the form x.y.z that doesn't match the library version anymore? I would love also to hear about from other users/packagers. > [1] Do you remember the SPDX license tags? It's better to use them [...] It's done. Regards, Francesco _______________________________________________ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
