[Koying]

Don't see it fostering debranding or forking either really, as it'd be much easier to long term maintain a service.unknown_source.updater

We are trying to be reasonable, by taking reasonable actions for reasonable users.
Using dirty tricks will only make the slope more slippery, by convincing the reluctants to take more drastic measures...

[learningit]

IMO learningit is blinded by his hatred towards TVA and isn't thinking about those dev's and their interests and I really hope no one takes that suggestion any further

Your opinion is yours alone. If you knew me and the discussions that I have been having, I have been putting the interests of add-on devs first and foremost. Sites like TVA which cross lines and attract litigation place all add-on devs at risk of being dragged in and becoming collateral damage. There needs to be a way to minimize that.

[User 325245]

You are becoming new Apple with these restrictions

[Lunatixz]

Best way to kill almost all addon development in kodi...

I don't see how? He is talking about repositories, not plug-in.

Sent from my SM-G935T (typie typie)

See my answer to Martijn

I was addressing his line of thought, and also share your concern about beta testers

See post #2 to Ronie

[natethomas]

You are becoming new Apple with these restrictions

I believe the team is very open to real feedback on this. They're probably going to be less open to feedback that is either a joke comparing them to Apple or feedback that suggests the writer isn't really aware of what the code is doing.

[anxdpanic]

We are trying to be reasonable, by taking reasonable actions for reasonable users.

Hopefully my alternate option conveyed the same.

Don't see it fostering debranding or forking either really, as it'd be much easier to long term maintain a service.unknown_source.updater

We are trying to be reasonable, by taking reasonable actions for reasonable users.
Using dirty tricks will only make the slope more slippery, by convincing the reluctants to take more drastic measures...

My statement there is just what I seen as the path of least resistance to long term circumvention and an example of a possible negative result of partial restriction with no user input.
If I took what you are saying correctly, I'm not sure that it would be a deterrent to users reluctant or not. Would something that updates their add-ons so they don't have to install from zip regularly seem like a dirty trick, drastic or convenient to the average user that is already installing from those sources?
Hope we never see it happen either way.

[Koying]

If I took what you are saying correctly, I'm not sure that it would be a deterrent to users reluctant or not. Would something that updates their add-ons so they don't have to install from zip regularly seem like a dirty trick, drastic or convenient to the average user that is already installing from those sources?

If I understood you correctly, and that you think about an addon that would install addons, bypassing the Kodi repo system, yes, I personally consider that as a dirty trick.
Obviously not to users who know what they are doing. But if that is the entry point to an addon, definitely yes.

And, to be clear, the "reluctants " are team members not (yet?) ready to accept even more restrictive actions...

[Av3nged]

Firstly, a feature like this is needed because I came home after a couple of weeks and found that my brother added two repositories that were recommended on an online tutorial. The first thought through my mind was I hope that they didn’t update any plugins that Ii had with something malicious. The ability to prevent something like that from happening would be a great idea.

My idea of how it could work:
The plugins in the override repository should not be able to be overwritten but the ability to set more than one repository as override repository is important. This is so that libreelec would be able to set kodi and their self as the override repository, if they wish to.

Regarding development plugins, adding .dev to the end of the id as previously suggested is a good idea. That being said installing a file that ends in .dev over the original is a must. To identify as a development plugin there could be a popup or the word development beside the version number when you download/update a plugin. The .dev should be invisible to all the other parts of kodi so, if you had a .dev version of a plugin that gets called by another plugin it should use the .dev version.

[anxdpanic]

I took the statement incorrectly then, thank you for the clarification. Agreed it'd be a dirty workaround and don't want to see it.
I don't want to deal with the numerous YouTube add-ons in the wild but also don't want to see user testing be negatively impacted in dealing with it. Hopefully a balance is found before getting more restrictive.

[User 182116]

I really don''t know why some would get their knickers in a twist over this.

To me it is simple.

You have an Official repository that contains addons etc that comply with the integrity of design that the Kodi team employs to give users the confidence of knowing the they are tried, tested and not riddled with any form of code that could be considered nefarious.

By not allowing those specific addons to be overridden, the integrity is maintained and so is user confidence.

It seems to stop nobody from developing their own version of an app but simply not allowing the official version to be overridden.

Just like there is an iPlayer addon in the repository and also other forks and versions of it that can be installed side by side if necessary.

There is no slippery slope and it's clear to me that the Kodi team are not attempting any form of suppression or unreasonable control.

Users should be delighted in knowing that there is such a wide range of additions that they can trust, which also helps with trust in the product, despite all the media crap out there that has sought to make Kodi a dirty word.

Get's my vote all the way.

[Gade]

Using a different ID like ".dev" for testing add-ons is a terrible idea for many add-ons; each add-on has separate settings, some shouldn't have two versions active so users must remember to disable stable versions when testing then disable the testing version and re-enable stable when testing is done and/or a new stable version is released, managing skin usage of add-ons and other dependencies is a pain, and add-ons would need to do even more to protect against multiple active versions. Kodi could be extended further to handle these issues, but it still seems a sub-optimal solution. Dev/testing versions would be better handled with "channels" like stable, beta, and nightly/alpha/unstable. An automated update submission to an official nightly and maybe beta channel will reduce the need for external repos in the first place.

+ a million to this!

I rely very much on my development repo for skin testing and bugfixing, and I know a lot of people use it daily.

This PR would mean people have to install 2 versions of the skin and switch from one to the other all the time - copying skin settings etc etc. This will no doubt discourage a lot of users from installing the repo.

While I completely follow the idea of this PR, the above will make developing skins and other addons much less flexible.



EDIT:
A solution to this problem could be adding an optional line to addon.xml where developers can write their testing repo, if they use one.

Code:

<repository>repository.gade</repository>

This repo can still override addons from repository.xbmc.org

[Koying]

Does the skin in your repo have the same ID as one in the official repo?

If so, then that's exactly what we want to prevent.

Just rename it to ".dev" if it's your own you want tested.
If you just don't want it in the official repo anymore, ask for it to be removed.
I don't even want to imagine yours is a fork, or it is *definitely* what this PR is intended to fight.

[Gade]

Does the skin in your repo have the same ID as one in the official repo?

If so, then that's exactly what we want to prevent.

Just rename it to ".dev" if it's your own you want tested.
If you just don't want it in the official repo anymore, ask for it to be removed.
I don't even want to imagine yours is a fork, or it is *definitely* what this PR is intended to fight.

Yes, Rapier is in the official repo and I'm the developer. The addon ID's are the same, so the skin updates all the time between the official versions and testing versions.

Adding .dev would make testing and development a lot harder as people will need to install two skins.

See my above post for a solution.

[nickr]

No but it certainly stifles development.

Many addons start with people playing around and installing their "homemade" addon directly in their kodi install. They shouldn't have to put their addon in the repo or compile kodi themselves to be able to install from a zip file or their own repo.

And where does it say that that will be the situation? Exactly, it's not stated any where.
Install from .zip or dump the addon in their own local install would still work. The proposal from learningit was to not allow other repos with auto updates which does not hinder development at home

My comment was more in relation to @learningit's suggestion encapsulated as

Anyone who wants to install 3rd party repos would be required to install a non-official build which is not supported by team kodi.

I think that suggestion is a step too far. I am presently neutral on the PR as it presently stands, and I am avidly watching with interest the comments of addon and skin developers.

[Koying]

Adding .dev would make testing and development a lot harder as people will need to install two skins.

I don't think so.
If your users want to use the "beta" channel, they'd just install the dev version from your repo, and uninstall the stable one.

The main difference is that, nowadays, it's a hard to revert decision, as reverting to stable means uninstalling the beta and your repo, and reinstalling stable.

With a different ID, you let your users choose:
- they install beta, like it, keep it and uninstall stable (if they want, they don't have to)
- or they decide they prefer stable, and uninstall it (or not, keeping it to see how the beta evolves)

You might notice that more users are willing to test and report on your betas if they know they can switch back to stable easily if something fails.

It's the same situation as with android apk, really. I already suggested to have a different ID for nightlies/alpha/beta to allow users to test without risking to destroy their stable setup, mimicking what many software does nowadays with "channels". That's what I do for SPMC.