Agreed with most points here, especially ronie's. Our goal should be to encourage users to keep auto-updates on. If we can't accomplish that, then we're forgoing much of the reason to have the repo in the first place.
And second, I'd like to reiterate Jonathan's point, which he said better than I could've: "Skins are such a personal thing (both to the designer but often more so to the user) that we need to ensure that the user has more control over the process of updating." I think that sums up this entire discussion very well. So, I'd like to put things in different terms. We can, for the purpose of this discussion, substitute "xbmc skins" for "windows updates". That makes things less personal to the authors, and hopefully allows everyone to think from the users' perspective. So I'll ask again in that context, can we agree that it would be rude for MSoft to remove a particular feature in Windows Explorer because they replaced it with one that they felt was "better"? Again, we're not talking about from Win7->Win8, we're talking about waking up one morning to find your production environment changed. Second, I think that many of the skin devs see skins as things for users to play with, and XBMC as an enthusiast project. I do too, and likely everyone on this list does as well. But I can assure you that there are tons of users out there who are strictly users of XBMC because it allows them to cut the cable/satellite cord. For them, it is very much a tool. So back to the Windows analogy, if you consider the software to be a tool to get a job done, it's a shaky position to say that the MSoft devs should change a program that I'm perfectly happy with, because they feel the new way is better. To that end, I think we need to represent the users here first. If a skin update changes too much and you don't want to support the old way anymore, no big deal, users will just have to wait for the next stable version of XBMC. For Eden anyway. For Frodo, I agree with the ideas proposed... "This update may reset your settings and/or remove some features, would you like to proceed?" and the major/minor scheme. Seems like the way forward. Lastly.. any plan that starts with "A user would just have to..." or "To avoid that, a user could..." is already headed down the wrong path IMO. The goal here should be to make things seamless for end-users. Regards, Cory On Fri, May 25, 2012 at 8:19 PM, ronie <[email protected]> wrote: > On 26-05-12 00:49, Jonathan Marshall wrote: >> A couple of comments on this: >> >> 1. First off, great discussion by all. >> >> 2. Skins are such a personal thing (both to the designer but often >> more so to the user) that we need to ensure that the user has more >> control over the process of updating. One method would be to change >> the auto-update switch to never/minor revisions/major revisions and >> default it to minor-revisions. >> >> 3. If 2 is done, we need a policy in place as to what is a minor and >> what is a major revision - it doesn't have to be burdensome, just >> something we all agree is best practice. I suspect most already use >> major.minor.fixup numbering anyway in revisions, so this should be >> easy enough to implement across the board. Reviewers would need only >> check that the minors don't contain major changes. >> >> 4. Even with the above in place, I think we need a re-think of how the >> current skin is updated. I'd suggest that this should always be >> precluded from auto-updates, thus always giving the user a choice. >> >> 5. Lastly, rollbacks are already possible, and should be possible >> without breakage regardless of version changes between major XBMC >> releases. This requires skin settings in particular to not change >> meaning between versions, but that is needed anyway for a clean update >> path (obviously no resetting of all settings - that builtin should not >> exist full stop). >> >> Note that 2 and 4 are XBMC-side changes, so we cannot do anything >> about this with respect to Eden. Let's keep the discussion going, >> though, so that Frodo handles this in a nicer way. >> >> Cheers, >> Jonathan >> > > my thoughts: > > - users should be encouraged to install updates as they almost always > will contain bugfixes > > - i don't have any stats to back this up, but i think only a minority of > our users does not want to receive updates > > so the 'best' setting for the majority of our users should be > 'auto-update enabled for all updates'. > > > - what qualifies as major, minor or fixup may be a grey area at times > and i don't think we should bother the end-user with 'tech talk' like that. > many of them might not even have a clue what they mean, so keep it > simple stupid, on/off for updates. > > > - we have to keep in mind that sometimes a script update will require a > skin update as well. > for instance a script may add some new items to their window xml, which > would require all skins including a custom skinned script window to > update as well. > if we enable auto-update for one, but disable it for the other, breakage > will occur. > > > i'd say, keep things as they are and add a 'notify me on skin updates > before installing' option (default off) to keep everyone happy. > if a user chooses to disable skin updates, he should be aware that > a) this could lead to breakage due to script updates > b) the skin author may not be interested in providing support for > deprecated skin versions > > > full ack on the settings/rollback suggestions btw. > > cheers, > ronie > > ------------------------------------------------------------------------------ > 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
