as discussed at http://drupal.org/node/94154 it'd be great if something could tell site admins if any of their installed modules are out of date and if newer versions are available. this would have to be a contrib in 5.x, but it might move to core in 6.x and beyond...
to make this possible, the .info files for 5.x modules need to to include some additional information so that the check_updates.module (or whatever we call it) can find the project node on drupal.org to make the XML-RPC calls or find the right RSS feed for info about new releases for that module.
the attached patch appends this data to all .info files (just like we're already doing with the human-readable version string (http://drupal.org/node/97286). here's an example of the resulting signup.info file on my local test site:
; $Id: signup.info,v 1.1 2006/11/13 05:14:44 wright Exp $
name = Signup
version = "$Name: DRUPAL-5 $"
description = Allows you to signup for events or other kinds of content on the site.
; Information added by drupal.org packaging script on 2006-11-17
version = "5.x-1.x-dev"
Project name = "signup"
Project home = "drupal.org"
any complaints?
thanks,
-derek
Comment | File | Size | Author |
---|---|---|---|
#3 | package-release-project-id.patch_1.txt | 4.9 KB | dww |
package-release-project-id.patch.txt | 4.96 KB | dww |
Comments
Comment #1
merlinofchaos CreditAttribution: merlinofchaos commentedIMO, 'Project name' and 'Project home' are perfect.
Comment #2
dwwtalked to dries about this. overall, he's happy with it, and basically said "you're the architect, do whatever you think is best". however, we hashed out some things both with the design, and the specifics of the data in the .info files...
so, the current proposal would look something like this:
if that
project = "signup"
is there, the check_updates.module would know it's a d.o-packaged thing. it'd just have to have hard-coded knowledge of the proper xmlurl to use to query for the updates (presumably something like drupal.org/project/release/updates but we'll have to finalize that later). it'd have the (project,version) pair to send in the query.basically, the only way to support the 3rd party case would be to do a more rigid thing in the .info file in the first place: adding a full-blown xmlurl field, not just a generic "home" where we conjure up the full URL, anyway. i think it's safe to just say we're only supporting d.o for now, and if someone wants to roll a whole system for another site, they can step up and i'll happily try to coordinate with them. until that happens, no sense over-complicating the common-case.
(setting to needs work since the patch is now stale from the current proposal, but i'm curious for more feedback on this before i plow ahead).
Comment #3
dwwnew patch that implements what seems to be the general agreement on how this should look.
i know the shell escaping stuff isn't exactly what some of the zealots prefer (escape at the last possible moment, depending on exactly how you're using the untrustworthy data), but i didn't feel like completely refactoring/re-organizing all the code. what's here is still secure, it's just less flexible if in the future we decide this script shouldn't be using shell commands (yeah, right). if that ever happens, we can reorganize all the escaping then. meanwhile, i have more urgent tasks to attend to.
so, any final complaints? otherwise, this is going to go live in a day or so. i already regret how many 5.x-* releases have been packaged without this.
-derek
Comment #4
dwwafter review from merlinofchaos, committed to DRUPAL-4-7--2 branch and installed on d.o.
Comment #5
(not verified) CreditAttribution: commented