XBMC minimum version now it's on Git?

I tried using <minversion app="xbmc">177d3cb</minversion> in my addon.xml because that's the how the nightly is labelled (xbmc-r177d3cb-master.exe) and that's also the build found in the system info but when I tested this using Dharma the skin still updated.

Neither. The tag is completely useless, and really should not be there at all.

Instead, we should be bumping the API version when things are added. I haven't as yet as we haven't agreed on how this should be done during the "things are in flux and might change quite a bit" phase of development.

I'll see if I can start a discussion about this and come up with some guidelines.

1. Check the versioning stuff does what it should do.
2. Bump the version and ensure that the user is informed as to why they can't load/install the skin (The dependency check is currently done after load unfortunately).
3. Look at when we should bump versions. This will probably become apparent after a while.

Other things to help is that we'll be looking at getting the buildbot to build my branch (or perhaps master + guilib branch merged) as I need it so that you guys can test out new code before it gets in - that way we should hopefully get more places where the feature goes in complete with version bump.

Unfortunately I suspect the version checks aren't done at all in Dharma, so it probably won't help with users attempting to install your skin there - never know though, we might be lucky!

xbmc.addon has been bumped to be version 11 (so inline with 'main' xbmc versions) so one way you can do it is make your repo (or skin if you want, but see below) dependent on xbmc.addon v11 or higher.

xbmc.gui has also been bumped to 3.00, with no fallback compatibility stuff anymore. Thus, if your skin depends on xbmc.gui v3.00 and the version of XBMC doesn't supply it, it won't install. Ofcourse, this won't apply to Dharma, as Dharma didn't have dependency checking that worked

I suggest having your repo depend on xbmc.addon 11, and having your skin depend on xbmc.gui 3. I'll try and remember to keep xbmc.gui updated as new stuff is added from here on, though I may well forget!

jmarshall Wrote:Yeah. Then (theoretically at least!) it won't install on eden b3, but will install on eden rc1 (on it's way...)

May I ask - say that in a month Watchlist script makes it as core functionality and I add skin support for it.

I push updated version of skin to MY repo, keeping skin name the same as is. Provided that user has nightly version installed with compatible xbmc.gui (say ver 3.1) he will be able to "see" new version and get update while Eden users stays safely with older version that is in official repo (xbmc.gui 3.0)?

No, the Eden user will not pull a skin that depends on xbmc.gui v3.1, as all the user has is xbmc.gui v3.00.

In the multi-repo situation (i.e. user has both your repo and the XBMC repo installed) then I'm not 100% sure what happens. i.e. will the user get only the most updated version of the addon (the one that requires v3.1 of xbmc.gui) listed, and thus won't be able to install it due to unmet dependencies? Or will the user be able to install the one from the Eden repo (the one that requires v3.0 of xbmc.gui). Reason I'm not sure is that dependency resolution occurs only on install, not prior to install (or after install).