Define version compatibility system for plugins (1 Viewer)

[arion_p]

I think you misunderstood how the compatibility system works. When you specify what version of MP your plugin is designed for, you are not saying that it is not compatible with any other future version. Also the designedForVersion is always considered in context along with all UsesSubsystem attributes you specify. I think a couple of examples will clear this out:

Case 1:
A plugin that is reorganizing the pictures database and does some background automation is being developed and built against SVN 27700. It has:

CompatibleVersion("1.1.6.27700", "1.1.6.27644")
UsesSubsystem("MP.DB.Pictures")

Now some time later we release Beta with a version number of 1.1.7.0 and no breaking changes in Pictures database schema or business layer. This means that the last breaking version no for the MP.DB.Pictures subsystem is still 1.1.6.27644 and as a result the plugin is compatible.

When later on we release RC1 with version 1.1.8.0 and ofc MP.DB.Pictures subsystem last breaking version still 1.1.6.2764, so plugin still compatible. Then we finally release 1.2.0 with version 1.2.0.0 and the plugin is still compatible
....
After many years and many changes to the Pictures plugin but no breaking changes to the Pictures database we are about to release MP version 1.99.0. The last breaking version of MP.DB.Pictures subsystem is still 1.1.6.27644 and the plugin is still compatible!

All this time the plugin developer never had to change a single line of code. He didn't even have to rebuild the plugin against newer MP binaries.

Case 2:
We have already released 1.2.0 Beta (version=1.1.7.0).
A window plugin that connects to social network X and presents the user the latest events, is being developed and developer is using 1.2.0 Beta to build against (although there are more changes in SVN after the release of 1.2.0 Beta). It has:

CompatibleVersion("1.1.7.0", "1.1.6.27644")
UsesSubsystem("MP.SkinEngine.Core")
UsesSubsystem("MP.SkinEngine.Dialogs")
UsesSubsystem("MP.Config")

Some time later we release 1.2.0 final (version=1.2.0.0) and no breaking changes since Beta, so all three subsystems have a last breaking version = 1.1.6.27644. The plugin is ofc compatible as expected.

Later on we find a serious bug (a memory leak). The only possible fix is to change so that we require all GUIWindow descendants to implement a new interface INewInterface that will handle resource allocation/deallocation. Unfortunately this change will break all plugins that define GUIWindow descendant classes (i.e. all window plugins) but we have no choice. So we commit this change in SVN 28905 and set MP.SkinEngine.Core last breaking version to 1.2.0.28905. Then a few commits later we release 1.2.1 as a bugfix release with version 1.2.1.0.

Now this time the plugin is no longer compatible because it uses MP.SkinEngine.Core which has a breaking change after the version the plugin was designed for.

The plugin developer has to implement the new interface in his GUIWindow derived class and then rebuild the plugin. He has to do this anyway for the plugin to work (and also not leak resources). He builds against 1.2.0.28949 (SVN 28949) which is a private SVN build that is being tested by the team (and available to community plugin devs). Because of the compatibility system he has to also change the CompatibleVersion to:

CompatibleVersion("1.2.0.28949", "1.2.0.28905")

That is the only additional change he has to make to make his plugin compatible with 1.2.1.
*Notice that the plugin developer has to make changes and rebuild the plugin regardless of the compatibility system.

Now we find a couple minor issues that we fix in SVN 28950 and 28951 and in the end 28951 is the final 1.2.1 which is release with a version 1.2.1.0 and ofc the newly built (against 1.2.0.28949) plugin is compatible with 1.2.1 as expected.


An additional point I would like to make is that it is expected that there will be no breaking changes once we reach the RC phase, so what is compatible with x.x.x RC1 should be compatible with x.x.x final. If we do decide to make a breaking change at this stage, rest assured that we will not do it lighthearted, and we will make sure we communicate this to all known plugin developers in advance so that they have time to do necessary changes to their plugins.

I hope this clears things out.

 

[Disore]

Hi arion_p,

thank you very much for your detailed answer. I totally misunderstood the designedForVersion argument, thank you for clearing that out!

Note to myself: make sure you understand the problem before spending other peoples time; and your own; ranting about non-issues

 

[thlucas]

Light dawns on marble head! So the bottom line is the MP developers are going to track version compatibility by subsystem, and not by the Core.dll assembly itself? At least that's what I got out of your detailed explanation (awesome BTW). In that case I think it will be ok, as long as you document the current list of subsystems and their versions.

Also, you might want to add the above detailed example to the "Version Compatibility" Wiki page:

Version Compatibility

 

[tourettes]

Note to myself: make sure you understand the problem before spending other peoples time; and your own; ranting about non-issues

Actually I think it was good that you brought those questions up. Definitely we didn't have good enough documentation in the wiki - now we can add those two good arion's examples to the documentation, I think it will help the other plugin developers a lot.

Also, you might want to add the above detailed example to the "Version Compatibility" Wiki page:

Yes, that should be added to there.