Jingai: Please be sure to cc the list. I believe what Jonathan was saying (and certainly my opinion) is that anyone who downloads and manually installs mods is out of the scope of this discussion. In your case, it's the equivalent of the Debian repo maintainers worrying about what happens when a user installs a random .deb they find on the net. At that point, the system is at the mercy of the user.
And the hold is somewhat moot here. What we've been discussing so far is that auto-updates should be fixes and improvements only, where anything that could cause breakage or something for you to "deal with" would require you to confirm it. In that way, it's automatically on-hold for you already. Could you describe an example where that wouldn't handle updates as you'd like? Also note that we're only discussing skins here so far. Regards, Cory On Sat, May 26, 2012 at 12:26 AM, jingai <[email protected]> wrote: > Why bother renaming it, changing the addon id, etc? Why not just let me hold > it? > > Most users who get mods from the forums just unarchive whatever they got > directly into the skin folder. They don't know how to change the ID or > anything else. > > For some perspective, I'm thinking of this like package management on a > Debian-based system. I frequently want to hold a given package at a specific > version or to skip a version. Like for instance, the 'synergy' package on > Debian unstable is at 1.4.8 but is incompatible with my two Macs that I have > sitting next to it. I don't want it to update until I'm ready to deal with > it -- time is precious to me, and as long as it does what I need it to do, > I'll postpone it. > > -j > > On May 25, 2012, at 10:42 PM, Jonathan Marshall wrote: > >> I'm not sure I get the issue with "hold this add-on forever". Surely the >> user modding the skin could "just" rename it something else and get that >> behaviour anyway? I don't see a "normal" user ever needing this? Folk that >> mod the skin just need to remember that the very first thing to do is change >> the add-on id. >> >> I think probably the best way forward is to prompt if the update involves >> major changes (either specified by the add-on, or via the versioning). The >> only problem with this is that other dependencies may have been updated >> which means the skin is effectively broken (unmet dependencies) - it will >> still "work" as we don't check deps at runtime, but some interaction there >> may be broken until the user actually updates. >> >> We don't have a system in place to hold back dependency updates. In fact, >> this is an issue that can occur already - there's nothing stopping an add-on >> being updated that drops backward compatibility for another add-on whilst >> that other add-on is installed as there is no reverse dependency resolution. >> The only way the user knows that it might not work is when it doesn't work, >> or if it's marked as broken in the repo. >> >> Cheers, >> Jonathan >> >> >> On Sat, May 26, 2012 at 2:01 PM, jingai <[email protected]> wrote: >> 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 >> > > > ------------------------------------------------------------------------------ > 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
