Over at #1314180: Make dev release numbers useful we're talking about changing elements of the version string for -dev releases. However, we don't want to completely rewrite the version strings, since that'd be changing the version values in the issue queue for -dev issues (the majority of issues, I'd guess), changing the tarball names, and other stuff which we don't (yet) want to do. But, we're going to have this other "version string when rebuilt" thing, something like "7.x-2.0-rc3+17-dev". Instead of *just* sticking that in the .info files during packaging, it'd be nice to record this string in the DB so we could display it on release nodes and maybe do other stuff with it. After an extensive conversation with hunmonk about it, we agreed that the basic concept of a version string specific to each rebuild was generic enough to just live directly in project_release itself (instead of being a d.o-specific hack in drupalorg_project).
The most obvious choice would be to add a 'rebuild_version' column to {project_release_nodes}.
However, that's going to be empty for most releases, so maybe it's better to just have a separate {project_release_node_rebuild_version} table with nid, rebuild_version columns. If we go the separate table route, we could even key off node revision id, not just the nid, and track how these change over time, although that's probably overkill...
Comment | File | Size | Author |
---|---|---|---|
#5 | 1401990-5.rebuild_version.patch | 6.28 KB | dww |
#2 | 1401990-2.rebuild_version.patch | 6.01 KB | dww |
Comments
Comment #1
dwwBased on a chat with nnewton in IRC, we agreed that a separate table is better for two reasons:
1) Saves some space.
2) Avoids needing to do a blocking ALTER TABLE operation during the deployment.
If, down the road, we decide we really wish this was in {project_release_nodes} itself for query optimization reasons, we can always move the data at that point. But for now, a totally separate table is probably the most simple solution.
I'll be working on a patch this afternoon, stay tuned...
Comment #2
dww(Since this is relevant for fixing -dev versions, which in turn is relevant for http://drupal.org/community-initiatives/drupalorg/distribution-packaging... tagging this appropriately...
Comment #3
dwwNote: this is everything except a change to the packaging plugin itself to actually populate this data. That can happen over at #1314180: Make dev release numbers useful.
Comment #4
hunmonk CreditAttribution: hunmonk commented{project_release_node_rebuild}
or{project_release_node_rebuild_metadata}
would be a better name for this table long-term, in case there's other data related to rebuilds that we want to store in the future?project_release_clear_rebuild_version()
, deleting a release node for a branch? in that case i'd call itproject_release_delete_rebuild_version()
, seems more clear.tested the upgrade path and exercised the API functions, didn't try a fresh install.
Comment #5
dww1) Sure, we can rename. Makes sense.
2) Yeah, renamed the function. That reminded me, we need to call this from hook_delete(). Also fixed.
Any final objections or shall I commit/push?
Thanks!
-Derek
Comment #6
hunmonk CreditAttribution: hunmonk commentedthere's a dangling
project_release_node_rebuild_version
in a code comment.also, just curious -- do you think we should add an API function for retrieving the rebuild metadata? right now our API is CUD, not CRUD ;) that could be used in the display code as well...
Comment #7
dwwCleaned up the final comment, committed to 6.x-1.x and pushed.
Thanks!
-Derek