Closed (fixed)
Project:
Project
Version:
5.x-1.x-dev
Component:
Releases
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
27 Dec 2007 at 10:44 UTC
Updated:
22 Mar 2008 at 17:33 UTC
Jump to comment: Most recent file
Now that project admins are nearly to the point where they can control supported|recommened|snapshot for each major version (see http://drupal.org/node/203313), we can start working on a patch to project-release-create-history.php to populate the release history XML files with the new attributes that are being added to update(_status) over at http://drupal.org/node/197186. The latest patch for #203313 is already on http://project.drupal.org, as is a copy of project-release-serve-history.php at http://project.drupal.org/release-history. So, we could install a patched version of project-release-create-history.php at p.d.o and people could point their update(_status) test sites there, and start testing the latest patches for #197186 with real data.
Any volunteers? This should be a very easy patch. You barely need to know anything about project*, just familiarize yourself with the new attributes via #197186 (in particular, http://groups.drupal.org/node/7440#comment-23536 option D.2 which is what we ended up going with), and the schema for {project_release_supported_versions} from #203313. project-release-create-history.php is pretty small and well commented.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 204140_release_xml_supported_versions_1.patch | 6 KB | dww |
| #1 | 204140_release_xml_supported_versions.patch | 3.92 KB | dww |
Comments
Comment #1
dwwUntested, but I think this will work. Handles
<recommended_major>and<supported_majors>. Also defines<project_status>for knowing when the project itself is unpublished.Comment #2
dwwSweet, that seems to work perfectly. ;) I love it when code just works. There's now a cron job running every 15 minutes on p.d.o with the patch applied. So, when folks play with the releases subtab on p.d.o, they can point their patched update(_status) clients at p.d.o and see things changing in terms of what's recommended, supported, flagged as needing to upgrade, etc.
Comment #3
dwwThere are some edge cases here when you've got a project without any supported releases for a given version of core. I think we still want to create the header info about the project itself, and have an empty "supported_majors" attribute or something. Or, maybe we should re-use the "project_status" attribute and set it to "unsupported" or some such...
Comment #4
dwwPretty sure this should do it. I went with re-using the project_status attribute, since that was the best way to handle it in the update.module patch, too.
Comment #5
dwwNow that #176776: GHOP #55: Make release summary table UI look more like update(_status)? report is live, this needs to go in, so I just committed to HEAD. I've gotta deploy on d.o, but it's too late for that right now, so I'm setting this back to active. I'll deal with this tomorrow.
Comment #6
dwwAlso committed to DRUPAL-5. I gotta get used to having the extra branch in here. ;)
Comment #7
dwwDeployed on d.o, ran, and emailed devel to let everyone know this was live.
Comment #8
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.