[Spice-devel] [PATCH 0/2] Make plugin version checking more robust

[Christophe Fergeau]

On Tue, Mar 27, 2018 at 10:28:24AM +0200, Christophe de Dinechin wrote:
> 
> 
> > On 27 Mar 2018, at 10:12, Christophe Fergeau <cfergeau at redhat.com> wrote:
> > 
> > With the right patch attached this time.. ;) I've only compile-tested
> > this as this really is just a proof of concept at this point.
> 
> If I understand correctly, you break the ABI twice,

Ah, could be, minimizing ABI breaks was not really a goal in that split.
What matters in my opinion is that we decide to break it, once we've
made that decision, the number of commits which are going to make ABI
breaking changes is less important.

> and you rely on a “side effect” of changing the variable name to avoid
> conflicts that would otherwise arise with the version number alone?
> 
> It makes the history fo the code harder to track, and the changes more
> “subtle". At the very least, I would add a commit log explaining that
> since you can’t rely on version numbers alone since the version
> numbering scheme changes, you renamed the variable used to track
> version numbering.

I don't understand this part :) 

> Also, that means you need to follow the same patterns in locksteps for
> the plugins, so you are not just making the history of the agent
> complicated, but also the history of the plugins.

Hmm how do we cope with ABI breakage with respect to plugins is an
interesting question. When the ABI is in flux in git, it's not going to
be easy to link an arbitrary plugin commit to the agent commit(s) which
have the ABI the plugin expect anyway, so I would say that we want git
master of the agent to work with git master of the plugins. I would not
require plugins to have at least one commit working with each commit of
the agent.
On that note, we should strive to never break plugin ABI, only extend
it. The plugins are in their infancy at the moment, so we can do some
breakage now while to put everything in place, but ideally we'd settle
on something stable "soon"

> So overall, a lot of additional complication. What is the benefit?

The benefit is that we don't have unrelated changes grouped together in
a big commit.

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/20180327/ece53c17/attachment.sig>