Last modified: 2013-01-08 20:44:33 UTC
ExtensionDistributor should check out a special hidden file for very extension package that includes information from our repository (say call it .info): For subversion it may be: - Branch - Revision (the important item) For git it may be: - Checkin ID (a hash) This is following bawolff's suggestion on IRC and the discussion happening over at https://bugzilla.wikimedia.org/show_bug.cgi?id=30955 about this. I'm not familiar with the systems, but one suggestion for how to go about it would be to make ExtensionDistributor check in a default .info file to the project (ensuring it has the right and latest format) then checking out the extension for packaging. It would have to ensure the special auto-prop is set. http://dev.juokaz.com/php/automatic-svn-revision-number-in-source-code I don't see a need for the file to be .php, we can just as easily parse it, however maybe .info.php would mean we could just include() it. In the short term this would provide an audit trail for administrators on what they installed (especially for extensions with no or inconsistent versioning). In the longer term I am working on a ExtensionUpdate Special page which could use these files, in combination with some new API calls (will file separate reports for those) and report to administrators which extensions (or mediawiki core!) need updating. One day we might even get to installing them from the web ala wordpress.
Good ole ini: # .extensiondistributor revision = r666666 path = /branches/REL1_17/extensions/Foo/
It should also put in the url of the repo, and the type of repo (svn, git, etc). I'm with Daniel, an .ini file would be great.
Not a Wikimedia site bug.
maybe a prettified .json file like this? --- .extensionDistributor.json { "repo": { "type": "git", "url": "https://gerrit.wikimedia.org/r/p/mediawiki/extensions/Cite.git", "branch": "master", "HEAD": "4c8c2623c2d932b1b59f2d5f730b06ea40a37693" } }
or how about a composer file? eh? eh? bandwagon! You could do like CI and run your own package repo even if you like instead of using packagist.
(In reply to comment #5) > or how about a composer file? eh? eh? bandwagon! You could do like CI and run > your own package repo even if you like instead of using packagist. Those are fine suggestions. Note though that contrary to a package manager manifest (which should be stored inside the repository itself), the proposal here is to add a source manifest, declaring what version has been downloaded etc. If we want to create or own package repo and/or use an existing one, that's a different (great) feature request. Something like Composer (the PHP version of NodeJS's NPM, basically) can be used without needing MediaWiki support actually. Afaik you can publish to it from any repository that has such a file, so that can/does work already.
True, my original request for a source file was to help with developing an automated updating extension. But there's no reason someone couldn't use composer for that. So even if they got the extension by downloading it, they could keep it up to date using composer, and extension distributor could make sure the file was there even if the extension didn't provide it themselves.
The new version (to be deployed on Jan 16th with 1.21wmf8) has users downloading files that include the sha1 in the filename. This should be sufficient, I think. Marking FIXED.
