LUMIERA.clone/doc/design/plugins/PluginVersioning.txt
Ichthyostega 0e08f269f5 remove the superfluous TiddlyWikis
..after integrating all still relevant asciidoced content
into the main website.
2012-01-11 06:55:54 +01:00

44 lines
1.5 KiB
Text

PluginVersioningCases
======================
:Author: MichaelPloujnikov
:Date Created: 200707121127
:Date Changed: 200707160404
:Count Changes: 46
//MENU: label Plugin Version
Compatibility matrix
--------------------
.Source compatibility
[grid="rows"]
`100`200`200~~~~
*~CALLER~ \ ^CALLEE^**,OLD^**^,NEW^**^
OLD,works,works but a recent interface definition must be available
NEW,works,works
~~~~
.Binary compatibility
[grid="rows"]
`100`200`200~~~~
*~CALLER~ \ ^CALLEE^**,OLD^**^,NEW^**^
OLD,works,works
NEW,caller gets "revision not sufficient" at runtime and should implement fallbacks,works
~~~~
^*^) CALLER is the user of an interface, CALLEE is the interface provider (usually a plugin)
^**^) OLD means an initial revision, NEW means some later revision of an interface
Observations
------------
Compiling a newer Plugin for some older main application release has some quirks (interface definitions are intended to be shipped with the main application). This should be rarely the case.
When compiling, older Plugins should be updated to new interface revisions.
Caller should provide a fallback to older interface revisions for binary compatibility.
Generally, sources should just be properly maintained and updated to use the most recent interfaces revision.
For binary compatibility everything will work well, provided that the caller kept proper fallback functionality for older interface revisions. Plugins which are independently distributed (packaged) in binary form don't need to be updated with every new main application release and just work.