Paddy I agree with you. And yes, we'll set policy as a result. This is a one-time thing that gets through only because it's not fair to punish the Nox guys for breaking a rule that didn't exist -- that's our (my) fault for not preempting it. The repo is not a playground, and the main issue I see is the disconnect from repo users and addon devs. That's not meant as any kind of criticism, it's only natural.
Skins are quite different than other addons in this case, and this is the first time a major change like this has come up. The problem with not pushing the update is that it only delays the problem until it gets bigger and worse; the skin has gone in this direction, and whether users get it in Eden or Frodo, they'll have to deal with it. As a rough draft on policy, i think it suffices to say just this: no functionality should be removed and no settings should be lost during an automatic skin update, no exceptions. If you have to break compatibility in a way that forces users to take action, it must be done in a new XBMC version. That said: Rutger/Philipp: Is it beyond the realm of possibility to sed the names to allow rollbacks before pushing this thing? You certainly would win my good graces that way. Regards, Cory On Tue, May 22, 2012 at 2:32 PM, Patrick Carey <[email protected]> wrote: > Realise I'm a bit late to the party here but I'd like to give my 2 cents, > not that it'll matter much ;) > > It's really bad form to push an update to users that will break their > existing setups. Most of the debate seems to be centred around the fact > that "well they must have installed it in the first place so they should be > able to deal with the change". That's really not the case, with XBMC's > userbase only growing by the day it's no longer realistic to assume that > only self-installs exist, I personally have installed openelec on some > (about 10) Revos for most of my family and all of those installs will have > to be "fixed" after the update. I'm sure I'm not alone in this, I would > imagine most XBMC setups have more than one user, and that not all of those > users would necessarily know how to re-setup the skin if needed. > > Changing look isn't an issue, it's the wiping out of the old settings > that'll need to be re-setup. I don't think that such a major change should > be left up to the authors of a plugin, isn't it the responsibility of those > managing the official repo to ensure as little breakage as is possible? I > don't think it's unreasonable not to expect major breakage during the > lifetime of a stable release, especially when it's avoidable (even if it > will cause temporary pain for the authors). Any unstable update is going to > reflect badly on XBMC as a whole, not necessarily the skin/script/plugin > that causes the breakage. > > Whatever the outcome of this, would it maybe be worth implementing some sort > of policy for the future to ensure at the very least string/settings > stability over the course of a stable release? Or maybe a change in the > addon system to indicate that an update may break compatibility with the old > settings and allow to disable those types of updates? > > Sorry for the rant ;) > Paddy > > > > > On 22/05/12 18:04, Cory Fields wrote: >> >> After a good bit of thought I've come to the same conclusion, it's the >> author's call here. I don't like this one bit, but if it's what the >> authors want I'll push and we'll watch the fallout. Be aware though, >> this will set a precedent. So if it users get pissy, you can bet we >> won't go down this path again. >> >> True the skin-look changes aren't the end of the world. The heart of >> the issue is that most users getting this change won't know what hit >> them. But you guys were right that anyone getting this update was at >> some point adventurous enough to install it on their own, so we're not >> talking about the average user. >> >> Also, this should be a lesson about reusing strings ;) >> >> Cory >> >> >> On Tue, May 22, 2012 at 8:14 AM, Philipp Temminghoff >> <[email protected]> wrote: >>> >>> i don´t really want to use skin bool labels which are more complex than >>> needed. >>> and i also do not want to get used to several hundred new bool names. >>> a skinner´s life is hard enough already ;) >>> >>> >>> On May 22, 2012 2:04 PM, "[email protected]" >>> <[email protected]> wrote: >>>> >>>> Poor machine having to do all the work of s and r? Contrary to humans >>>> they >>>> love repetitive tasks you know ;) >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> Xbmc-addons mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/xbmc-addons >>> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Xbmc-addons mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/xbmc-addons > > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Xbmc-addons mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbmc-addons
