[Spice-devel] [PATCH 1/2] Ensure that plugins cannot bypass version check

[Christophe Fergeau]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20180405/eefc9c03/attachment.sig>