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...

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dww’s picture

Based 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...

dww’s picture

Status: Active » Needs review
Issue tags: +drupal.org distribution blockers
FileSize
6.01 KB

(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...

dww’s picture

Note: 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.

hunmonk’s picture

  1. wondering if {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?
  2. what's the use case for project_release_clear_rebuild_version(), deleting a release node for a branch? in that case i'd call it project_release_delete_rebuild_version(), seems more clear.

tested the upgrade path and exercised the API functions, didn't try a fresh install.

dww’s picture

1) 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

hunmonk’s picture

there'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...

dww’s picture

Status: Needs review » Fixed

Cleaned up the final comment, committed to 6.x-1.x and pushed.

Thanks!
-Derek

Automatically closed -- issue fixed for 2 weeks with no activity.