[Gade]

@Gade - what about dependencies of dev add-ons? Like, what if you work on a all new Rapier version that requires changes to some other script/library (skin helpers, ...) that are not in repo yet, and these changes might not be backwards compatible? So even if your skin could be overridden the way you suggested, what about the dependencies? At least to me it would make most sense to have a .dev version for all of these testing related add-ons/modules so that they can be tested without the risk to break other add-ons etc and with an easy way to revert to a stable version (like koying suggested). I don't see a real advantage of your suggestion (besides of keeping add-on settings, but Kodi could probably copy the settings from "non .dev" to ".dev" when such a version is installed).

I actually encountered exactly this during the refactor of script.skin.helper.service. I wrote in the official release threads of Rapier that people testing the development version should install the latest script.skin.helper.service from Git and install from zip.

Let me understand this correctly. Do you recommend for the development version of Rapier to use the development versions of dependencies? Eg. script.skin.helper.service.dev?
Marcel, maintainer of this script, use a testing repo as well - so his development versions would be named script.skin.helper.service.dev.

This would break all dynamic paths using this scriot and all script checks etc.
I could do a search and replace in the entire skin to use script.skin.helper.service.dev, but that's IMO a very slippery slope opening up for all kinds of possible errors.

[anxdpanic]

Skins/add-ons, yes skin.dev will know to hardcode dep1.dev dep2.dev and would have to maintain those id's(in Rapier as an example there is ~20 references to just script.skin.helper.service) manually as they change from version to version back and forth from .dev to stable as those dependency versions change during skin.dev's own cycle. dep1.dev turns stable during skin.dev cycle but dep2.dev doesn't etc, and repeat during each round.

Then say YouTube, how many add-ons have plugin.video.youtube hardcorded somewhere? How would a user help test a change to plugin.video.youtube.dev doesn't break any of those add-ons or something like Yatse sending to YouTube on Kodi?

Seems dealt with now with addon.xml dependency version="", there are ~alpha/beta tags for between versions which don't affect the addonid, and users that are testing having the proper channels for those dependencies. Yes, a more complete rollback solution and proper channels would be nice but I don't see this as solving either. My self would rather see a setting for alpha/beta/stable channels which follows the current version tags, and creating a proper rollback for stable releases in the current addon manager as a solution to that problem.

[rmrector]

I'm digging Gade's idea of a home repository tag for add-ons. ONLY honor the repository tag that is declared in the official repo, then tampering is much harder (always verify the addon.xml/.gz cached against a strong hash from the server). Also, instead of declaring a repo by id, use the "datadir" / base URL of the repo, so that if a nefarious version with the same ID were to be installed first it still wouldn't override anything. Encourage SSL for repos and users are protected without crippling a feature. Better thought out and implemented changes "not worth the hassle" is bull when trying to justify this lazy approach that hurts legitimate uses and users; something does need to change to improve security in this regard but it will take a bit more work to do right.

Dev and testing versions as different installs ".dev" works for some software but not others, same for add-ons, so forcing it is not a good solution. Sometimes a beta of an add-on should be used in place of the stable version without swapping to a dev version of a skin, or a module with an existing script, or a dev skin should use the most recent version of an add-on, which may be dev for awhile but later pushed stable.

[jurialmunkey]

The main concern with skins is the transfer of settings between .dev version and official version. If there is a simple solution (for the end user) to easily copy over skin settings between .dev and official version then that would help. Ideally, when installing a dev version of an already installed official skin (or addon), there should be an automatic prompt asking if they want to migrate the skin (or addon) settings over.

There would also need to be a way to then copy the skin settings of the dev version back to the official skin when they are done testing and the official version has been updated and now suits their needs. If there isn't an easy way provided to do this, then I can see end users being very reluctant to try out beta versions for bug fixing purposes because it would mean they have to spend a considerable amount of time setting up the skin again exactly how they like it.

[jurialmunkey]

Dev and testing versions as different installs ".dev" works for some software but not others, same for add-ons, so forcing it is not a good solution. Sometimes a beta of an add-on should be used in place of the stable version without swapping to a dev version of a skin, or a module with an existing script, or a dev skin should use the most recent version of an add-on, which may be dev for awhile but later pushed stable.

Thinking about this more, I'm becoming more opposed to the whole .dev idea. For instance, like the others, I'm wondering how this might work with something like SkinHelper.

Say I want to try out a beta of skinhelper, or skinshortcuts or extendedinfo. I wont be able to uninstall/disable the official version because it will be a dependency of some skins. However, if I install the beta version anyway then I will have two versions of the same addon both trying to set the same window properties. How are conflicts like this going to be dealt with?

Also, like others have pointed out, many of these scripts have calls from within the skin. How does the skin also call the .dev version? How are people going to be able to test out these addons if the skins aren't linking to the dev version?

[Koying]

The problem of hardcoded addons id for "HasAddons" is a valid one, agreed.

I'd propose to the Team to alter the functionality of "HasAddons" to accept, eg, any "skin.helper.*" as valid for the check, which would mimick the current way of working, while leaving the door open to actually test for the ".dev" version, which would actually be an improvement vs. the current situation.

Is there other part in code where the addon id has to be hardcoded?

PS I see plenty of valid points for a *test* environment exposed here.
Please understand that advanced beta users using beta skin using beta addons is not what we firstly have in mind, here, but rather the 99% of "plain" unsuspecting users being abused...

[da-anda]

would it be an option if core would automatically check for ".dev" versions of referenced scripts/add-ons in case the currently running add-on/skin is also a .dev? That way skinners wouldn't need to change anything in skin code and only set the dependency to .dev add-on in the addon.xml (and they even could include the .dev version in their repo for easy setup for testers).

[jurialmunkey]

The problem of hardcoded addons id for "HasAddons" is a valid one, agreed.
I'd propose to the Team to alter the functionality of "HasAddons" to accept, eg, any "skin.helper.*"
Is there other part in code where the addon id has to be hardcoded?

There is also RunScript:

Code:

RunScript(script.globalsearch)

And content plugin paths:

Code:

<content target="videos">plugin://script.skin.helper.widgets/?action=recommended&mediatype=movies</content>

Addon label localization

Code:

<label>$ADDON[script.extendedinfo 32115]</label>

And skin shortcuts uses its own hooks into addons:

Code:

<shortcut label="$LOCALIZE[31017]" type="32010">||BROWSE||script.skin.helper.service/?action=smartshortcuts</shortcut>

And activate window to a plugin path:

Code:

<onclick>ActivateWindow(videos,plugin://plugin.video.youtube/search/?q=$INFO[ListItem.Artist],return)</onclick>

PS I see plenty of valid points for a *test* environment exposed here.
Please understand that advanced beta users using beta skin using beta addons is not what we firstly have in mind, here, but rather the 99% of "plain" unsuspecting users being abused...

I get this, I am really supportive of the general idea - I just see a number of practical issues. I also don't think installing a beta version of an addon is that advanced. It is exactly the same process as attempting to install any 3rd party repo.

My problem isn't that my skins depend on a beta version of an addon. Rather, it is that they depend on the *official* repo versions and that will stop those addons from being uninstalled. So when a user wants to test a bugfix in the beta version of skin helper, installing the .dev version will result in them having TWO versions of skinhelper. This is a problem because skinhelper runs as a background service that fills window properties, so you now have two addons simultaneously trying to fill the same window property.

These addons require skin integration. Without a way to have a beta version override the official version, there will be no way for users to test them out without making a lot of skin changes. It isn't going to break skins, but it will stop the addons having beta testers.

would it be an option if core would automatically check for ".dev" versions of referenced scripts/add-ons in case the currently running add-on/skin is also a .dev? That way skinners wouldn't need to change anything in skin code and only set the dependency to .dev add-on in the addon.xml (and they even could include the .dev version in their repo for easy setup for testers).

See above. My issue is not that my skins depend on beta versions (they don't, they use official versions). The problem is that these add-ons require skin integration, so they will require the skinner to make changes to the skin just so an end user can test out a bugfix in the add-on.

[mikeSiLVO]

Oh boy, this is a complicated issue.

I think that using the Kodi default repo as an override is a great idea. The issues brought up previously by others are also of great concern. Personally I would love if I could make use of this somehow but the fact that I work on and distribute a skin mod make that highly unlikely.

The balance then becomes when to override and when not too.

Development for addons, skins, scripts, or plugins becomes more difficult to those that want to and should test outside of the Kodi repository before submitting.

I think the response from tamland should also be considered.

No matter what is done there will always be those that can and will circumvent whatever safeguards are put in place. The fact is all code is readily available so it pretty much guarantees that it will happen eventually

Denovo = Cracked
AACS = Cracked
CSS encryption, Sony ARccOS, UOPs, APS, RCE = Cracked

None of that is open source but was still circumvented none the less.

You might make it difficult for the ones who make use of the lack of any roadblocks in Kodi but to quote Ian Malcom

"Life finds a way..." Replace Life with piracy and there ya go

I do not think this is a bad idea at all. I personally like the idea. I hate users posting issues that are ALWAYS due to whatever B.S. they have installed...

IMHO the benefits do not outweigh the hassle to those that have nothing to do with the reason for this being considered in the first place.

Perhaps what tamland suggested is the way to go?

Remove cross-repository updates completely and print to log the home repository so that info will show regardless if Debug is active or not.

Something doesn't work then the log will show where you got the addon from and boom post/thread binned.

I know this solution will not stem the tide of all the waste of time posts but I, admittedly not the smartest person, cannot see a way where this does not hurt the ones that should not be affected just as much as those that should...

[scott967]

Dev and testing versions as different installs ".dev" works for some software but not others, same for add-ons, so forcing it is not a good solution. Sometimes a beta of an add-on should be used in place of the stable version without swapping to a dev version of a skin, or a module with an existing script, or a dev skin should use the most recent version of an add-on, which may be dev for awhile but later pushed stable.

Thinking about this more, I'm becoming more opposed to the whole .dev idea. For instance, like the others, I'm wondering how this might work with something like SkinHelper.

Say I want to try out a beta of skinhelper, or skinshortcuts or extendedinfo. I wont be able to uninstall/disable the official version because it will be a dependency of some skins. However, if I install the beta version anyway then I will have two versions of the same addon both trying to set the same window properties. How are conflicts like this going to be dealt with?

Also, like others have pointed out, many of these scripts have calls from within the skin. How does the skin also call the .dev version? How are people going to be able to test out these addons if the skins aren't linking to the dev version?

I agree that this creates a can of worms for developing skins. Even something simple as Artist Slideshow needs a bunch of work if skinner has to use some sort of "beta" skin setting toggle to call out different addon ids. So as example I suppose all window properties used to pass info from addon to skin need two versions of id and then skin has to use boolean conditions to pick the "right" one. For users of SHS that seems like a real burden.

scott s.
.

[pkscout]

I agree that this creates a can of worms for developing skins. Even something simple as Artist Slideshow needs a bunch of work if skinner has to use some sort of "beta" skin setting toggle to call out different addon ids. So as example I suppose all window properties used to pass info from addon to skin need two versions of id and then skin has to use boolean conditions to pick the "right" one. For users of SHS that seems like a real burden.

I was just getting caught up on this thread, and as the maintainer for the simple example above, I agree. I would basically have to stop public beta testing for AS and just hope that my sample of two machines is enough to catch any bugs I introduce when updating things. And given I know my coding quality, I can say with some authority that it won't.

[skybird1980]

i think at all this will result that no addon dev will give his addon to main kodi repo and will use a free one..

[Rantanplan-1]

im not a huge Fan of the ".dev" "solution"/suggestion.

what about a Setting/Button in "DialogAddonInfo" to allow to installing a testing Addon(-Version) for that specivic Addon (from another Repo) (Same ID).

[L0RE]

I dont Like The Idea. I Undestand the Problem, But i would prefer if there is Setting "Install always newest Version" that could be activeted.. SO normal User Are safe, but User could Change that it they want, "Like the Setting Yes i want third Party Addons"

If it realy to Always Kodi.tv over Other Repositorys, i hope removing my addons is possible.
If not i will Use New IDS and stop putting Versions in Kodi.tv

[Razze]

First of all I like what this is trying to do. I don't like what this means for developers. While the channels thing would be awesome, in this stage of discussion the ".dev" feels tacked on.
In the best case we would need an easy way for a dev to go with a beta build to normal (aka remove ".dev" everywhere) and to enable channels and have it organized nicely we probably need some server changes.
That would mean core would have to automagically understand that this is a dev version and take the right actions to wire it up correcty.

Please don't quote me on this I'm thinking out loud and might have gotten things wrong.

I'm digging Gade's idea of a home repository tag for add-ons. [...]

I'm a bit worried about performance for that solution. But well might only be bad if you actually have multiple repos installed.

The main concern with skins is the transfer of settings between .dev version and official version. If there is a simple solution (for the end user) to easily copy over skin settings between .dev and official version then that would help. Ideally, when installing a dev version of an already installed official skin (or addon), there should be an automatic prompt asking if they want to migrate the skin (or addon) settings over.

There would also need to be a way to then copy the skin settings of the dev version back to the official skin when they are done testing and the official version has been updated and now suits their needs. If there isn't an easy way provided to do this, then I can see end users being very reluctant to try out beta versions for bug fixing purposes because it would mean they have to spend a considerable amount of time setting up the skin again exactly how they like it.

But transfering settings won't solve your problem, it might make it worse. Like your dev addon has some new options, settings get copied from normal, settings are gone. Your code tries to get them - crash or worse an invisible bug