On May 25, 2012, at 8:19 PM, ronie 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
I definitely agree with all of this. Normal users should just get updates automatically by default. A mechanism to notify them of potential breakage could be a good thing, but in general, most users won't understand why they want to or don't want to update. And they'll just complain on the forums when things don't work right. Maybe instead of doing a major/minor/micro/etc thing, just have a flag that addon authors can set to indicate that the user would have to reset their settings. If the flag is set when installing the new version, pop a dialog warning the user before it is updated. As I said before though, for the users that *do* know why they don't want to update, a hold system would be a good idea. IMHO, I think I should be able to say: 1) Hold this addon forever at the current version, 2) Skip the available updated version, but auto-update with the next one. For either or both, it could still pop a dialog suggesting that an update is available, but the point is that users shouldn't be afraid of leaving auto-updates enabled when they've made local changes. For skins in particular user modifications seem common enough to warrant this. It would also help skin developers to work in-place without having to do silly things like bumping the version to 9.9.9 etc to prevent XBMC from overwriting the tree. -j ------------------------------------------------------------------------------ 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
