Hey, My two cents. First a personal anecdote: I was pissed enough about a smallish usability change in confluence in dharma->eden update to file a bug (which was dismissed, much to my disappointment). It's bad enough when functionality breaks at major updates - so do not break anything for current users via auto-updates, and don't put any silly prompts for users to ignore. Also don't force users to mark something as "held", it's just silly to assume that an average joe would bother to hold anything or even bother to find out that this hold thing is about.
So here's my suggestion to keep best of the both worlds: xbmc addons in general would auto-update only "minor" versions (as per Cory's original statement), but also allow "major" updates to be available from the stable repo that can be manually installed (also, new installs would always install the latest version). This would mean some fiddling with the current repo system to both allow multiple versions in the repo and some fiddling with the addons UI to allow updates (but do NOT prompt update yes/no, just tell somewhere that there are updates available). This will of course require some effort from addon maintainers, if they want to issue bugfixes to the older versions. (Effort is quite minimal, if you're familiar with any version control system that allows "branches" - not very different to what you do when a new "pre" repo becomes available.) Here, "major" and "minor" would probably need some hardcoded version number rules to keep keep things simple enough. I don't think a "flag" system would work very well. Something like x.y.z, where x and y updates are not auto-updated, but z updates are. Probably somewhat more strict guidelines than current are necessary, something like "minor update must not add new dependencies", to keep dependency problems minimal. To continue the windows analogy, you could stay on IE8 and get the bugfixes, but you could also install IE9 and get all the new fancy stuff and then get autoupdates for the new major version too - both are supported on windows 7. Viljo Viitanen 2012/5/26 jingai <[email protected]>: > Sorry about not CC'ing the list. > > But no, the Debian maintainers don't worry about what the users do, because > they allow the users to hold the packages. I can manually > compile/install/modify a package and keep it for as long as I like, and it > won't get overwritten, because I can put the package on hold. Granted, I can > achieve the same thing by renaming it (appending my own revision, etc), but > it's also something your average-joe-user won't do. > > I concede that this is a different issue than what you're trying to solve, > although I do think it's related, which is why I brought it up now. > > You're going to have a hard time policing the updates to make sure they are > only "fixes and improvements." That's so subjective with skins in > particular. Putting more control into the users' hands helps solve that. > > -j > -- Viljo Viitanen [email protected] ------------------------------------------------------------------------------ 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
