On Wed, Apr 18, 2018 at 12:47:42PM +0100, Frediano Ziglio wrote: > From: Christophe de Dinechin <dinec...@redhat.com> > > A major.minor numbering scheme is not ideal for ABI checks. > In particular, it makes it difficult to react to an incompatibility > that was detected post release. > > [More info] > > The major.minor numbering scheme initially selected makes it harder > to fixes cases where an incompatibility was detected after release. > > 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. > > 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]. > > Since the change required for #1 and #2 introduces an ABI break, > it is as good a time as any to also change the numbering scheme, > since changing it later would introduce another unnecessary ABI break.
Fwiw, I'm not sure yet I fully understand the rationale behind this, and the various pros and cons (see https://lists.freedesktop.org/archives/spice-devel/2018-April/042956.html and https://lists.freedesktop.org/archives/spice-devel/2018-April/043175.html) The rationale mentioned in https://lists.freedesktop.org/archives/spice-devel/2018-April/043151.html would probably be good to have here if we decide to go with this versioning. Christophe
signature.asc
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
