https://bugzilla.wikimedia.org/show_bug.cgi?id=30955
--- Comment #12 from Daniel Friesen <[email protected]> 2011-09-18 03:41:39 UTC --- Imho what we really need is a way to subscribe to updates on when something like an extension is changed. SVN wise for awhile I've wanted to be able to define patterns of svn paths (ie: extensions, and some interfaces I care about) and even some regex pattern to catch changes in code I consider relevant and have e-mails sent to me on commit. Larger extension wise people may not want alerts for every single commit though svn alerts are a start. Besides the ability to subscribe alerts we also really need to embed branch and original Wikimedia rev info when an extension is downloaded or checked out. And we need an easy way to query a Wikimedia api to see if the revs or versions have changed. Version numbers, update alerts. I don't believe either of those are really effective at all at letting users know when to update in other software. In WordPress at least I'm quote sure that the most effective way users are kept up to date is WordPress' plugins page listing plugins that have been updated since the the version you have was released. And such a thing has little to do with encouraging every single extension to publish version numbers. For a small extension where just about every new rev is a fully functioning release with very minor changes which are really fixing small bugs and code style tweaks there is practically no advantage to defining a version number over just using rev ids to know when an extension should be updated. However note that WordPress also combines this with a community of users commenting on the compatibility of an extension with a version of WordPress. We also have avoided this kind of thing for awhile because the act of indiscriminately making http calls out of the box has a number of implications in security, performance, and privacy. It also has other issues with some hosts restricting the ability to make outbound http requests. And also requires that Wikimedia keeps some service running indefinitely that piles of MediaWiki installs will be making calls to. The first thing we'll probably need is a service that actually tracks revs, published version numbers, branches, and versions of MediaWiki. From there the simplest thing to start with would be a Special:Version feature that has a link called something like "Check for extension updates" which would be a link to the service containing an encoded set of the current MediaWiki version, what extensions are installed, what branches those extensions came from, their Wikimedia revision ids, and any published version numbers. Then the service would use that voluntarily submitted information and compare it to the current status of those extensions and inform the user if there are any updates. After that we would consider expanding it into a full api and adding some way of having MediaWiki make the calls itself. That said, I don't know how nice the idea of changing "This wiki has version <x> of extension" to "This wiki has version <x> of extension, the latest version of <y>, you should update this extension." when in our case just about anyone looks at Special:Version for various purposes. And unlike WordPress we don't really have any special dashboard primarily used by the people that have the ability to update the install. Later on we may want to consider things like letting extensions give a custom definition of places to look for updates. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
