On Tue, Apr 17, 2018 at 06:39:05PM +0200, Christophe de Dinechin wrote: > When does this kind of scenario happen? Imagine we added support for > loading/unloading plugins. Version 13 adds a new interface to unload > plugins, and a new “unloadable plugin” entry point. Therefore, > starting with version 13, the agent would try the new entry point > first, and if it’s there, assume it can unload the plugin, otherwise > fallback to the old method and mark the plugin as not-unloadable. > Therefore, the change in version 13 would still be binary compatible > with version 3. Years later, in version 21, we decide to drop support > for non-unloadable plugins. So now the agent refuses to load a plugin > if it does not have the new entry point. In that case, we’d want to > bump the “compatible version” to 13, since all plugins after 13 have > that new entry point. The key win here is that we’d not have to force > the last compatible version to be 21. > > This could mean years of differences in terms of binary compatibility. > We could deprecate things slowly and offer graceful transitions. This would work if all that is needed to use the new interface is a recompile, and not active porting, or if we make sure plugins using the old interface can no longer be built when version 13 comes around. If we are instead considering a method used in version 10 which is called 'my_method'. version 13 deprecates 'my_method', and replaces it with 'my_new_method', but API/ABI compatibility is kept with version 10, so I can rebuild my plugin calling 'my_method' against version 13. I assume the plugin ABI version would become 13 after being recompiled? Then in version 21 I decide to remove 'my_method' because it's been long obsolete, but my plugin recompiled against version 13 will no longer work. Am I missing something, or misusing this? Christophe
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel