Kodi Community Forum

As anyone who has run Gotham alpha's since A9 knows, the xbmc.python bump caused a bit of a hassle. On the plus side, that hassle highlighted some bugs, on the minus the constant nagging isn't much fun...

If a change is required anyway due to things being broken, then fair enough, the minimum backward compatibility version needs bumping.

However, if things aren't broken, why force add-on authors to make changes they wouldn't otherwise need to do?

I propose that we revert the xbmc.python minimum versioning to 2.0, under the assumption that it is still backward compatible to 2.0. If it's still compatible, there's no reason to bump it.

Opinions most welcome - if there's a decent reason why it was bumped, then please elaborate what that is.

Cheers,
Jonathan

Just from a Software Development view - versioning is a straight forward thing when understood. Depending on the changes you bump either major (feature), minor (api change),Patch (bugfix). It doesn't match our addons System - but if API was not changed - no need to bump (by change i mean incompatible change - not API features).

My 2 cents

ok let me start:

in Frodo we dropped
- httpapi
- gui lock / release
- and others i can't even remember
and we didn't do a version bump and even kept the 1.0 backwards compatibility which should have been done. Even until two months ago (or so) the version was still 1.0

in gotham we changed:
- changes in play method regarding playlists as those seperate methods were dropped. http://forum.xbmc.org/showthread.php?tid...pid1559503
- skin localization $LOCALIZE[SCRIPTXXX] was dropped http://forum.xbmc.org/showthread.php?tid...pid1521453
- scripts use videodb:/2/2/ path in JSON queries which is not supported any more.
- maybe some other hidden ones
so again these thing are enough to do a bump.

The constant nagging is a bug in core which has nothing to do with this. It should ask once and be done with it.
I'd even say now we have unmet dependencies and incompatible separated we should just notify that it will be disable if it has a broken tag instead of asking if they want to disable.

So all these are more than enough to warrant bumping backwards compatibility. All of this was the reason I (we) bumped the version.
Also I already contacted most addon devs who I could trace back asking to update their addons to latest changes. Heck some addons where ported back from Dharma repo.
As a side note it was on my request that we now have a combined repo list inside XBMC. We could just use Gotham repo and said that every devs should send a new request to also have their addon in Gotham. So that would have meant there would be absolutely nothing in gotham repo and we wouldn't even have this discussion.....
my 2cents as a repo maintainer...

sorry for OT, but when does a addon have unmet dependencies and when is it considered incompatible? If a skin depends on an addon that's not compatibel, will it itself also be incompatible or only have unmet dependencies? IMO there is no reason to see an addon in the list that I can't install, regardless why. (it's a different thing if it is/was already installed)

As for the version bump. Sounds sane to me. Currently there are already some addons in the repo that don't work anymore (for whatever reason, be it the python magic by jfcarroll or something else) and are not marked as broken (I only remember MMA-fighting or so which I once wanted to try). So anything marked as broken might actually be broken and should in best case be tested.

(2013-11-29, 12:42)da-anda Wrote: [ -> ]sorry for OT, but when does a addon have unmet dependencies and when is it considered incompatible? If a skin depends on an addon that's not compatibel, will it itself also be incompatible or only have unmet dependencies? IMO there is no reason to see an addon in the list that I can't install, regardless why. (it's a different thing if it is/was already installed)

correct, if a skin depends on a add-on that is not compatible it is in turn also not compatible due to unmet dependencies.
if goes as far that if skin X depends on add-on Y that depends on add-on Z and Z is missing something all will be incompatible.

Quote:As for the version bump. Sounds sane to me. Currently there are already some addons in the repo that don't work anymore (for whatever reason, be it the python magic by jfcarroll or something else) and are not marked as broken (I only remember MMA-fighting or so which I once wanted to try). So anything marked as broken might actually be broken and should in best case be tested.

if you notice that something is broken/doesn't work for sure let us know and we will kill it. Ofcourse there need to be some sound reason why it doesn't work anymore more.

As mentioned on github already if the add-on devs don't respond before beta release i'm willing to go through the addons to see if they indeed still work and then bump the API version myself to indicate it still works. If it doesn't it will be marked broken and hopefully the dev will update it again in due time.

Frodo had version 2.1.0 of the API, and backwards compatibility to 1.0.

Gotham's backward compatibility was bumped to 2.0 in https://github.com/xbmc/xbmc/commit/8fb5...88f51f2aa0 reflecting new features. I see no problem with that bump as it reflects changes made since Frodo, and this caused no issues whatsoever, as no add-on in the official repository requests anything prior to 2.0. At this point, the version was 2.13.0, backward compatible to 2.0.

No new features have been added since then, and nothing has been removed. So why bump the minimum version to 2.1.0 ? The reason given in the commit message was "set python API backwards comaptible version to minimal Frodo version". When queried the response was here:

https://github.com/xbmc/xbmc/commit/e3ff...nt-4542067

A heap of add-ons in the Frodo repository have 2.0 as the version they require. By bumping the minimum backwards compatibility version you've just made every single one of those add-ons no longer installable in Gotham. For no reason whatsoever, as from the API perspective it's identical to when the 2.0 bump was done. Either the 2.0 bump was wrong, or the 2.1.0 bump was unnecessary. I suspect a combination thereof.

Any bumps must consider what the add-ons in the repository are depending on. It needs to be done pragmatically. Yes, some add-ons won't work anymore as they depend on videodb://2/4/ or they might have cosmetic issues due to them using LOCALIZE(SCRIPTXXX) labels. But they're a small subset of the add-ons in the repository, and it wouldn't be all that hard to find them via git grep. Thus, instead of just breaking ALL add-ons, you instead break those that use the features that are no longer available.

As it is currently, we're in the situation where you can't even test those add-ons that haven't yet been bumped to 2.1.0 to see whether they work for reasons other than the above as they're not installable in Gotham.

I propose that there's 2 ways forward:

1. Keep backward compat at 2.0.
* Find the add-ons that are really broken due to the above listed changes.
* Drop their minimum API version to 1.0 (works with Frodo, won't work with Gotham).

2. Keep backward compat at 2.1.0.
* Find the add-ons that are really broken due to the above listed changes.
* Bump every other add-ons minimum API version to 2.1.0 (works with Frodo and Gotham).

I'd suggest that the first of these is less effort as you're touching a smaller subset of the add-ons.

Cheers,
Jonathan

Quote:Frodo had version 2.1.0 of the API, and backwards compatibility to 1.0.

this should already have been 2.0 to start with.
the 2.0 bump in gotham should have been 2.1.0 to reflect the changes. this whole backwards compatibility never got any proper attention and now they start complaining because it's getting used.

Quote:Hundreds of add-ons in the Frodo repository have 2.0 as the version they require

this completely grabbed out of thin air and not based on facts.
a factual grep in repo shows ~65 addons that have 2.0
95% of them already got an e-mail of me asking to update.

Quote:As it is currently, we're in the situation where you can't even test those add-ons that haven't yet been bumped to 2.1.0 to see whether they work for reasons other than the above as they're not installable in Gotham.

i certainly can test them if you know how which i already told on github.


and to make the story short we already choose option 2 before this whole discussion started....
i have the feeling i keep repeating myself and i want to hereby close this discussion for me

Quote:the 2.0 bump in gotham should have been 2.1.0 to reflect the changes. this whole backwards compatibility never got any proper attention and now they start complaining because it's getting used.

Ok, so the original bump was wrong and should have been a higher version. Nonetheless, if that had been a higher version we'd be in the same circumstances we are in now.

Users are complaining because an action taken by us caused inconvenience for them. Naturally, they don't understand why their add-ons have been marked as broken as they work just fine. These are users we rely on for testing stuff out - pissing them off means they're less likely to test stuff out. I already have a user who will now not test a crash fix because of the hassle caused. That crash will remain unfixed until someone else comes along to test it.

Quote:this completely grabbed out of thin air and not based on facts.
a factual grep in repo shows ~65 addons that have 2.0

Not quite thin air - I estimated based on a sample - admittedly it was not representative as I used the first page on SF IMO 65 is still too many.

Quote:i certainly can test them if you know how which i already told on github.

Sure, you can, but it's a pain in the arse as you have to install them manually.

The much, much better way to handle this would be to fix up the add-ons first (easy as you can test them out), and then bump the version in Gotham.

Quote:and to make the story short we already choose option 2 before this whole discussion started....
i have the feeling i keep repeating myself and i want to hereby close this discussion.

I'd kindly request that before any such bumps are done again that you discuss it first by putting it up as a PR. That way there's a (small) chance that we won't have the same issue next time around.

Principle is simple:
1. Bumping backwards compatibility WILL break stuff for users.
2. Do everything possible to minimise that breakage before the bump is done.
3. This means bumping versions of add-ons in the repository as much as possible before the bump hits users.

In the meantime, let's hope those 65 add-ons are fixed up promptly.

Cheers,
Jonathan

discussion was done between repo maintainers. should be enough and does not need a PR.

Quote:Sure, you can, but it's a pain in the arse as you have to install them manually.

or simple setting it back to 2.0 local and install them one by one and trying them out. not that hard.

Quote:I already have a user who will now not test a crash fix because of the hassle caused. That crash will remain unfixed until someone else comes along to test it.

well to bad then. i still have several crashes that until now also go unsolved and we already know the cause or PR is pending on some minor issue. beside my bet is that he relies on non repo addons of which we do not speak.

these are still nightlies so users should expect things not working.


as a heads up:
GUI bump will be done too as already discussed and decided by ronie and me because of the many changes and inconveniences that non-Gotham skins cause. so you can expect this in due time as well.

Quote:discussion was done between repo maintainers. should be enough and does not need a PR.

That's not wide enough. It's a change that has wider implications than just the official repository. While indeed concerns by repo maintainers should be first and foremost, we mustn't overlook that others in the team can check implications that *may* cause issues. In this case, I would have strongly advised against a bump until the majority of add-ons in the repository had been updated and all python modules had been updated.

I'm OK with the intention of a gui bump as stated on git, but please still do it via a pull request so I have time to check the implications in detail. Again, ronie and yourself are not enough here. The API maintainers must also be included, as should the wider team out of courtesy.

In the meantime, thanks again for going through and updating a bunch of add-ons in the repository - it is greatly appreciated, and we can consider this closed.

Cheers,
Jonathan

most should be updated by now.
some (27) i won't touch though as i have no idea if they still work and i will leave them for the addon author

Thanks heaps - greatly appreciated!

Do I understand this correctly that this min-requirement was already in place, but just wasn't marked as such? So most add-ons that are working now in Frodo should keep working in Gotham (minus skins and some other specialty stuff), but some need their addon.xml file updated to reflect that? Or is there more?

Correct - the minimum requirement has always been there, but was set too low to actually acheive anytihing. Then it was bumped to 2.0 but that didn't do anything as all add-ons in the Frodo repository were already depending on version 2.0.

Once it was bumped to 2.1.0 (as technically Gotham is not BW compatible with Frodo), a bunch of them would probably still work, but weren't installable. Now, most of them have been bumped to 2.1.0 so they'll be installable again. Many have also been fixed by their authors.

And yes, in Gotham you get both the Frodo and Gotham repositories - add-on authors can continue to just use the Frodo repository if there's nothing they need from the new features in Gotham. Or, if they like they can maintain 2 separate versions (one with less or different features for Frodo, one for Gotham) or one for Gotham and ditch Frodo - up to them.

Cheers,
Jonathan

The one thing of course we can not control are the 3rd party repos.
The only thing i could do was to get the word out as much as possible that devs check their code and make needed changes. This was already done nearly a year ago and again last month.
Sadly sometimes the news/changes does not always reach them so lets hope they will get notified by users that something changed.

During the check of the repo addons it also became apparent that some addons didn't even work anymore due to site changes and no one ever reported them as actually broken. So we should also make it more clear to them that if would be great if they could give us a mail saying it needs to be set broken.