Define version compatibility system for plugins | Page 2

Discussion in 'General Development (no feature request here!)' started by arion_p, February 3, 2011.

  1. arion_p
    • Team MediaPortal

    arion_p Retired Team Member

    Joined:
    February 7, 2007
    Messages:
    3,352
    Likes Received:
    1,447
    Occupation:
    Developer
    Location:
    Athens
    Ratings:
    +1,522 / 0
    Home Country:
    Greece Greece
    Show System Specs
    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:
    Code (Text):
    1. CompatibleVersion("1.1.6.27700", "1.1.6.27644")
    2. 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:
    Code (Text):
    1. CompatibleVersion("1.1.7.0", "1.1.6.27644")
    2. UsesSubsystem("MP.SkinEngine.Core")
    3. UsesSubsystem("MP.SkinEngine.Dialogs")
    4. 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:
    Code (Text):
    1. 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.


     
    • Like Like x 2
  2. Google AdSense Guest Advertisement



    to hide all adverts.
  3. Disore

    Disore Portal Pro

    Joined:
    February 27, 2009
    Messages:
    72
    Likes Received:
    8
    Ratings:
    +9 / 0
    Home Country:
    Sweden Sweden
    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 :oops:
     
  4. thlucas

    thlucas Portal Pro

    Joined:
    February 11, 2011
    Messages:
    133
    Likes Received:
    73
    Gender:
    Male
    Occupation:
    Computer Programmer
    Location:
    Omaha, NE
    Ratings:
    +83 / 0
    Home Country:
    United States of America United States of America
    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
     
  5. tourettes
    • Team MediaPortal

    tourettes Retired Team Member

    Joined:
    January 7, 2005
    Messages:
    17,301
    Likes Received:
    4,595
    Ratings:
    +4,810 / 3
    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.

    Yes, that should be added to there.
     
Loading...

Users Viewing Thread (Users: 0, Guests: 0)

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice
  • About The Project

    The vision of the MediaPortal project is to create a free open source media centre application, which supports all advanced media centre functions, and is accessible to all Windows users.

    In reaching this goal we are working every day to make sure our software is one of the best.

             

  • Support MediaPortal!

    The team works very hard to make sure the community is running the best HTPC-software. We give away MediaPortal for free but hosting and software is not for us.

    Care to support our work with a few bucks? We'd really appreciate it!