Followup from #642114: Compute and maintain the update status for every release node now that #635892: Create a project_package module for packaged install profiles on d.o is in...
In general, the update_status for a release is determined by other releases of the same project on the same branch.
However, in the case of package releases, it's more accurately determined as a summary of the update status values of each release included in that package. So, we either need project_release to invoke a hook when it's computing the update status for a given project, or we need to special-case package releases inside project_release_compute_update_status() or something. Opening an issue as a place to discuss.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 645076-2.project_package_update_status.patch | 6.24 KB | dww |
Comments
Comment #1
dwwHad a long chat with hunmonk earlier tonight about this. We ended up agreeing that:
A) We want to denormalize this data and store it, not compute it on demand via fancy views handler magic.
B) We just want to clobber the {project_release_nodes}.update_status column for packages so that it always holds the max() of its own update status based on other releases on the same branch of the package, and the aggregate update status of all its items included in the release. In practice, this means that package releases which think they're current might be not-current or not-secure based on included items.
C) A hook is overkill here. We're just going to special-case it and test if (module_exists('project_package')) and directly call a project_package function.
Comment #2
dwwComment #3
dwwCommitted to HEAD