On Fri, Mar 23, 2018 at 01:05:23PM +0100, Christophe de Dinechin wrote: > 3. Major.minor numbering scheme > > The major.minor numbering scheme initially selected makes it harder > to fixes cases where an incompatibility was detected after release. I'm still of the opinion that we should break ABI as little as possible, this is assuming that 1) we are going to break ABI 2) we are going to mishandle it, which hopefully will be a very rare occurrence ;) > > For example, the major.minor version checking assumes that agent 1.21 > is compatible with plugins 1.21, 1.13 or 1.03. If later testing > shows that 1.13 actually introduced an incompatiliy, you have to > special-case 1.13 in the compatibiliy check. Why special-case? I would declare 1.13 broken, and release 1.13.1 with a fixed ABI, or with a proper versioning to indicate ABI broke. Am I understanding correctly that the main benefit of this versioning compared to the current major.minor versioning is that you don't have to rebuild plugins built against 1.13 if you realize after the fact that 1.13 broke ABI? > > An approach that does not have this problem is to rely on incremented > version numbers, with a "current" and "oldest compatible" version > number. This is used for example by libtools [1]. "libtool" not "libtools". Note though that libtool versioning won't handle the case that you describe at least on linux as when you break ABI you want to change the library soname, and while you can do that in version 1.21, this won't change the soname of version 1.13 if it was marked as ABI compatible with the previous releases. Christophe
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel