Define version compatibility system for plugins (1 Viewer)

arion_p

Retired Team Member
  • Premium Supporter
  • February 7, 2007
    3,373
    1,626
    Athens
    Home Country
    Greece Greece
    In the past we have had issues with plugins being incompatible with newer versions of MediaPortal due to some breaking change in MediaPortal itself. While we always try to avoid doing changes that break existing plugins, sometimes we just have to do it in order to solve some issues properly. This has caused frustration for the users and a lot of wasted time for the team trying to process bug reports that were the result of those breaking changes.

    Recently there was a breaking change that requires that all plugins be rebuilt against the new version of MediaPortal. We are now taking the opportunity to implement a version compatibility system that will ensure that in the future incompatible plugins will be automatically detected and disabled, providing a smoother upgrade experience and less wasted time for the Team.

    The new version compatibility system has been already implemented for the most part, but it requires that we categorize MediaPortal functionality/APIs into subsystems. Since MP1 has no defined API and plugin developers pretty much use whatever they find suitable for the task, it is really hard for us to do the categorization in a meaningful way. This is why we are asking for the help of the community to make proposals and have an open discussion.

    IMPORTANT: Before you post please read the description of how the new Version Compatibility system works in our wiki page: Version Compatibility - MediaPortal Wiki

    I also would like to point out that each subsystem should correspond to extisting MP functionality and needs to be unambiguously defined. We are planning to start by defining the subsystems coarsely in the first version then later on we can refine the categorization by extending the subsystem hierarchy adding more levels.


    Thanks,

    Arion
     

    fforde

    Community Plugin Dev
    June 7, 2007
    2,667
    1,702
    42
    Texas
    Home Country
    United States of America United States of America
    Moving Pictures uses the SQLite bindings provided by MediaPortal. This may not be enough for an entire subsystem and to my knowledge there have never been any breaking changes, but it might be a good idea to include this in one of the "subsections".

    Also the wiki page does not provide specific information on assembly tags. I would like to get tags implemented as soon as possible so as soon as they are finalized, further information there would be much appreciated.
     

    thlucas

    Portal Pro
    February 11, 2011
    133
    146
    Omaha, NE
    Home Country
    United States of America United States of America
    Hi Arion_P,

    I'm fairly new to the MP plugin development, so bear with me if my questions and concerns bear no merit. :)

    I see a couple of potential issues with the CompatibleVersionAttribute. For one, specifying this attribute immediately make the plugin assembly unusable in prior releases of MP since the "CompatibleVersionAttribute" class is not defined in previous MP Util.dll assembly versions. Plugin authors will need to maintain 2 seperate versions of their code if they want to support MP v1.1.1.x deployment. Granted they could use conditional compile statements and maintain one set of source, but multiple run-time versions (and installers) would be required.

    Another issue is what version string do I specify in the attribute? I'm assuming it's the AssemblyVersion and not the AssemblyFileVersion. Or do I use the descriptive version? For example, in the docs it says the 1.2.0 Beta = 1.1.7.0 - which do I specify in the attribute value - "1.2.0" or "1.1.7.0"? It sounds like the developers need to publish a list of MP version constants that they want us to use, as well as keep them updated for future versions. The same goes for the "UsesSubsystem" attribute - not for sure what to put there either.

    Food for thought.
     

    arion_p

    Retired Team Member
  • Premium Supporter
  • February 7, 2007
    3,373
    1,626
    Athens
    Home Country
    Greece Greece
    I see a couple of potential issues with the CompatibleVersionAttribute. For one, specifying this attribute immediately make the plugin assembly unusable in prior releases of MP since the "CompatibleVersionAttribute" class is not defined in previous MP Util.dll assembly versions. Plugin authors will need to maintain 2 seperate versions of their code if they want to support MP v1.1.1.x deployment. Granted they could use conditional compile statements and maintain one set of source, but multiple run-time versions (and installers) would be required.

    There have been other breaking changes in 1.2.0 Beta that also require maintaining separate versions of plugins. That is the reason we pushed the version check in 1.2.0 Beta.

    Another issue is what version string do I specify in the attribute? I'm assuming it's the AssemblyVersion and not the AssemblyFileVersion. Or do I use the descriptive version? For example, in the docs it says the 1.2.0 Beta = 1.1.7.0 - which do I specify in the attribute value - "1.2.0" or "1.1.7.0"? It sounds like the developers need to publish a list of MP version constants that they want us to use, as well as keep them updated for future versions. The same goes for the "UsesSubsystem" attribute - not for sure what to put there either.

    The versions used are the AssemblyVersions. These can easily be determined by checking the version tab in the properties window of each assembly (checking MediaPortal.exe should be enough - all other assemblies should have the same version, otherwise you have a broken installation). In the example above the right version is "1.1.7.0". BUT you should use the actual version of MP the plugin was built against. So if you built your plugin against the current SVN (which right now happens to be 27700) the version to use is "1.1.6.27700". All (almost) released versions are tagged in SVN so there is no need to publish any additional list of version constants, nor is it practical.

    Regarding the UsesSubsystem attribute: the available subsystems have been listed in the wiki but not all have been clearly and unambiguously defined. Since we do not have a well defined public API, it is rather hard to accurately define the subsystems so at first the definition will be a bit loose, resulting in false detections of incompatible plugins. Still this will be better than having no version check at all, and by getting feedback from the plugin developers we can gradually have more strict definitions of the subsystems and even go into more fine grained definitions.
     

    fforde

    Community Plugin Dev
    June 7, 2007
    2,667
    1,702
    42
    Texas
    Home Country
    United States of America United States of America
    There have been other breaking changes in 1.2.0 Beta that also require maintaining separate versions of plugins. That is the reason we pushed the version check in 1.2.0 Beta.

    As a matter of fact the Assembly Attributes you are now requiring are the only change I have not yet been able to work around. Pretty much everything but these attributes can be handled with some clever reflection in a MediaPortal 1.1 environment. Until you added this, the latest version of Moving Pictures would work with MediaPortal 1.1 and the latest SVN just the same. I understand the reasons for your changes, and I am not really complaining here, just pointing out that thlucas has a point, because of this and only this, it probably wont be possible to have a plugin that supports MediaPortal 1.1 and 1.2 the same.

    The versions used are the AssemblyVersions. These can easily be determined by checking the version tab in the properties window of each assembly (checking MediaPortal.exe should be enough - all other assemblies should have the same version, otherwise you have a broken installation). In the example above the right version is "1.1.7.0". BUT you should use the actual version of MP the plugin was built against. So if you built your plugin against the current SVN (which right now happens to be 27700) the version to use is "1.1.6.27700". All (almost) released versions are tagged in SVN so there is no need to publish any additional list of version constants, nor is it practical.
    I am sorry but this is absolutely absurd. If you expect plugin developers to tag their releases with which MediaPortal versions they support you need to publish a list of official version numbers along with whatever breaking changes may be included in each subsection for a particular release. If you are not willing to do this then you have bitten off more than you can chew and you might want to think about rolling back this version tagging stuff...
     

    arion_p

    Retired Team Member
  • Premium Supporter
  • February 7, 2007
    3,373
    1,626
    Athens
    Home Country
    Greece Greece
    I am sorry but this is absolutely absurd. If you expect plugin developers to tag their releases with which MediaPortal versions they support you need to publish a list of official version numbers along with whatever breaking changes may be included in each subsection for a particular release. If you are not willing to do this then you have bitten off more than you can chew and you might want to think about rolling back this version tagging stuff...

    I really don't understand why you seem so upset with my response. All I am saying is that the list of version numbers is already published in SVN, why do you need it published again as a separate list.

    Also note that official releases are already known. E.g. 1.1.2.0 =1.1.2, 1.2.0.0 = 1.2.0 etc. Alphas, Betas and RCs are not actually official releases, they are in fact test releases (just more stable than SVN builds which may be completely broken).

    But all that doesn't really matter, the version number you use should be the version number in the properties of the MP assembly you reference in you project. If you build your plugin now against a build of the MP SVN #27700, it is simply wrong to set the compatible version to 1.1.7. It really should be 1.1.6.27700. Otherwise you are just looking for trouble. In fact I was looking for a way to avoid having plugin developers set this version by hand but could not find a generic solution. Short of that I hope that we can soon have a tool that will automatically update the CompatibleVersion attribute using the version of the referenced MP assemblies at build time. Unfortunately it won't be in the 1.2.0 beta time frame.

    Still I do not understand why you find checking the assembly version in Windows Explorer or in Visual Studio (properties on the referenced assembly) harder/more work than looking it up in the wiki and trying to figure out which of the published version numbers to use :confused:.

    Regarding documenting breaking changes and related versions/subsystems, you know very well that we have already started documenting all plugin related changes (not only breaking ones). I also already said that subsystems need better documentation (most actually are not documented at all :eek:) but that cannot happen overnight and we need all the help we can get. What did not occur to me is that we can also include in each breaking change documentation, the subsystem(s) affected. That is a great suggestion and would help gradually define subsystems more accurately but in itself is not enough.

    The reason is that you need to know what subsystems you are using LONG BEFORE the breaking change is introduced and categorized as breaking one of the subsystems. Once the breaking change is in SVN and documented in wiki, you cannot go back and change the UsesSubsystem tags on already published plugins.
     

    thlucas

    Portal Pro
    February 11, 2011
    133
    146
    Omaha, NE
    Home Country
    United States of America United States of America
    Here's an idea - Instead of the "CompatibilityVersion" attribute, why not add another method to the GUIWindow (or IPlugin interface) for version checking? This would still accomplish the same goal of allowing MP to check for version compatibility, but give the plugin more flexibility in handling the check. example:

    /// <summary>
    /// Check plugin version compatibility against the current version of MediaPortal core.
    /// </summary>
    /// <param name="currentVersion">Current MediaPortal core version.</param>
    /// <returns>True if plugin is compatible with the specified version of MediaPortal; otherwise, False.</returns>
    public bool CheckCompatibility(AssemblyVersionAttribute currentVersion)
    {
    // check version compatibility here. return true if compatible; otherwise, false.
    }

    MP core would call this interface method, passing the Core.dll AssemblyVersion attribute value. If the plugin returns true then all is well; if false, then unload the plugin and move on. Just an idea.

    I still think the subsystem attribute is a waste of time. The plugin developer will know if their plugin works with the specified compatible version or not. Why the need to specify a subsystem? If the plugin specifies that it will work with version x.x.x.x, then it will work - it's that simple.

    And even then the plugin is not guarenteed to work with each and every skin for a version that it supports, as I recently found out when trying to add support for the XFactor skin to one of my plugins! It turns out that the XFactor skin did not implement the virtual keyboard support, even though the plugin worked fine in other skins (Blue3, PureVisionHD, StreamedMP, etc).

    I guess my take is that it is up to the plugin developer to ensure that the plugin works with a specified version of MP, and document that up front. The user downloading the plugin should know what MP version they have installed, and only download the plugin if it is documented as compatible.

    Thanks - TL
     

    tourettes

    Retired Team Member
  • Premium Supporter
  • January 7, 2005
    17,301
    4,800
    I still think the subsystem attribute is a waste of time. The plugin developer will know if their plugin works with the specified compatible version or not. Why the need to specify a subsystem? If the plugin specifies that it will work with version x.x.x.x, then it will work - it's that simple.

    Subsystem versioning is not a waste of time - since plugins cannot know beforehand if some future MediaPortal release is compatible or incompatible all plugins would always need to assume that the next MediaPortal version is incompatible. With subsystem versioning we can allow the compatibility check to be done against the actual changes not jsut some "fictional" application version that doesn't tell anything about the real compatibility.

    Core version check would be all that we would need if someone can predict future - but at least I haven't heard that anyone would have such gift.
     

    Disore

    Portal Pro
    February 27, 2009
    72
    16
    Home Country
    Sweden Sweden
    I would like to continue the discussion regarding the designedForVersion argument in the CompatibleVersion attribute. It is clear from this thread that I shouldn't enter 1.2.0.0 here even though all my efforts at the current time is concentrated towards supporting that version. You are in fact saying that I cannot support that version until it has been officially released, because I need to verify that my plugin is compatible. I think this is, in mild terms, a pompous standpoint from you MP developers.

    I think compatibility should go both ways. I agree with you MP developers saying: "ok, guys, we have some problems regarding crashes in MP, where it in fact isn't the code in MP's fault but instead some plugins not being developed in the same fast pace as MP" (kudos to that by the way, we all know the time you put into moving MP forward). Implementing a way to inform the user that a plugin is pretty old and not compatible with newer installation of MP is perfect, I applaud it, but you also need to think about us plugin developers. It is not acceptable for us to release a new plugin version each time the build or revision part of the MP version is changed. In fact keeping a plugin up to date with SVN will become impossible. Not only that, but when you release the next official version of MP no plugins will be compatible if you don't hold the release a week or so, and clearly state the exact version you will release.

    I am proposing the following, please implement the CompatibleVersion attribute in a way that we plugin developers can specify the compatible MP version by setting designedForVersion to e.g. "1.2.*", because I think that compatibility should go both ways. I think that when you release your first RC, we plugin developers should be able to verify our plugin against it and be very certain that our plugin will be compatible with forthcoming RCs as well. If you read between the lines, I am insinuating that there should be no changes to any public class, method or interface in RCs, only internal MP bug fixes. You see, respect should go both ways. :)
     

    Users who are viewing this thread

    Top Bottom