It doesn't sound like holding an addon is any worse than what we've already got, according to what Jonathan said there.
It sounds like the real issue is that we're seeing a need for real dependency resolution.. a lot more difficult, but I don't see how allowing a user to hold an addon makes it any worse than it currently is. -j On May 26, 2012, at 12:23 AM, Cory Fields wrote: > Yep, A hold system is overkill for us. Our addon system just doesn't > have the smarts for it, and we don't have the man-power to test all > configs. Just testing "everything latest" consumes enough time/effort. > Imo as far as we should go is confirmation before download/install. > > As for setting a flag vs using major/minor version: I'd much prefer a > flag. Our system shouldn't dictate how an author versions. As an easy > example, front-row uses svn revs to dictate version. So svn r1234 is > v1.2.3 of the addon (or something like that). We already enforce point > bumps for new XBMC versions out of necessity, I'd rather not > complicate it further. > > Jonathan: I'm missing why deps would be broken? Surely we can prompt > before we even download? > > Regards, > Cory > > On Fri, May 25, 2012 at 10:42 PM, Jonathan Marshall > <[email protected]> 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
