Blocker for #635892: Create a project_package module for packaged install profiles on d.o, depends on #642110: Add native support in project_release for a "Security update" term ...
Once we know what term(s) in the "Release type" vocabulary mean "Security update", we're going to want to remember the latest security release on every branch, so we can more easily compute update status and display it. Having this denormalized in the {project_release_supported_versions} table is going to make the views and the resulting queries much more simple and less expensive.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | 642112-9.prsv-latest_security_release.patch | 12.53 KB | dww |
| #9 | 642112-9.prsv-latest_security_release.interdiff.txt | 4.22 KB | dww |
| #8 | 642112-8.prsv-latest_security_release.patch | 8.74 KB | dww |
| #5 | 642112-4.prsv-latest_security_release.interdiff.txt | 2.91 KB | dww |
| #4 | 642112-4.prsv-latest_security_release.patch | 10 KB | dww |
Comments
Comment #1
dwwThe huge "word" in the title makes tracker an issue listings ugly on my phone. ;)
Comment #2
dwwThis should be cleaned up based on #642094: Move the code to build the query that drives project_release_find_latest_releases() into a shared helper function and #642096: Provide a better mechanism for sorting releases with version_extra defined: introduce version_extra_weight but it's a start...
Comment #3
dwwRerolled to apply cleanly now that initial patches for #642106: Add native support in project_release for a "Release type" vocabulary and #642110: Add native support in project_release for a "Security update" term are in, and used "API tid" in descriptions in project_release.install whenever possible to disambiguate.
Comment #4
dww- Simplified project_release_find_latest_releases() so we only need a single query. We just keep looking through the releases on the branch until we find a security update (if any) to initialize $latest_security_release, instead of building and executing a whole new query.
- Fixed a bug spotted by hunmonk when we INSERT INTO {project_release_supported_versions) where the VALUES placeholders didn't match the columns and parameters (I was missing a %d).
Comment #5
dwwHere's the interdiff between #3 and #4.
Comment #6
dwwActually, now that I think about it, the hook_update_N() in here should run *after* the one from #642096: Provide a better mechanism for sorting releases with version_extra defined: introduce version_extra_weight that would add the version_extra_weight field. So, marking this blocked on that (and probably #642094: Move the code to build the query that drives project_release_find_latest_releases() into a shared helper function while we're at it).
Comment #7
dwwBoth of the blockers are now in HEAD, so this is active again.... stay tune for a reroll.
Comment #8
dwwComment #9
dwwAt hunmonk's request, now with a big fat comment about what's going on with the project_release_check_supported_versions() call in the hook_update_N() functions.
I also added views support for {prsv}.latest_security_release. While I was at it, I noticed that we weren't exposing explicit relationships on these nids, which come in real handy for making fancy views like a view of projects that show their latest, recommended, and latest security releases...
Patch and interdiff relative to #8 attached.
About the only thing I can think of left in here after this patch is to fix up project/release/views/handlers/project_release_handler_filter_release_node_nid.inc to handle this new field, too, but that could probably just go to a totally separate issue.
Comment #10
dwwFYI: see #643576: Allow filtering by latest_security_release
Comment #11
dwwhunmonk liked the comment, so I committed to HEAD. On to #642114: Compute and maintain the update status for every release node ... ;)