make releases into real nodes?

merlinofchaos and myself schemed about this in IRC for a while, and are more and more leaning towards this as the solution to numerous problems/features we want from the new release system. another nice feature that we'd get for free: ability to unpublish bad releases...

we're basically thinking:

required fields:

• project (stored as nid)
• project version (string -- this could be the "title" of the node)
• drupal core API version this is compatible with (string -- a branch of core, not a specific release)
• body (release notes)

optional fields:

• file (URL, either a link to a file in the release directory, a file attached via upload.module, or a link to an external site like sourceforge).

the cvs.module (if enabled) would add another required field "CVS release tag", the tag in CVS that the release should be built from, along with some kind of setting for "enable external packaging based on cvs tags" or something. so, we'd turn that on on d.o, but folks wouldn't be forced down this path if they were using project.module + cvs.module on other sites if they wanted to handle releases differently.

access control would be such that only the owner of a given project node (and maybe, the people w/ cvs access -- TBD) could add release nodes with that project id (nid of the project).

we'd probably need a few of the fields in the current {project_releases} table, including some kind of "status" bit that indicates if the tarball has been generated for the release yet or not.

a few other things that would be possible/easy/already-done with this approach:

• could promote a release to the front page (e.g. the drupal-core 4.8.0/5.0.0 release)
• via hook_form_alter() and hook_nodeapi(), other modules could extend the basic release node type to do other cool stuff or site-specific modifications

• taxonomies could apply to releases
• block of "most recent releases" is trivial
• releases show up in "recent posts" for free

ok, enough brain storming about why this is good. ;) any downsides? i'd like to get the blessings of some of the "heavy hitters" before merlin and i dive into the implementation details.

one quick note: we would NOT have a whole new release node for every nightly development tarball. i'm imagining there'd be a single node for each branch, where the CVS release tag just pointed to a branch tag, and the release notes would say something about this is just a nightly development snapshot, not a real release. as per my comments in http://drupal.org/node/58066, the version string would be something like "[project_name]-4.7.x-1.5dev". perhaps we'd want some magic filter or keyword substitutions so you could refer to the next-available-release-version automagically, instead of having to remember to update the nightly development release node each time you add another real release...

thanks!
-derek

thanks for the support so far.

@merlin:
I was thinking that the development 'releases' wouldn't be release nodes.

the more i think about it, the more convinced i am that a node should represent the nightly development snapshot "release" on every branch. via the cvs.module, next to the field for the cvs tag to build the tarball from, there should be a checkbox for if you want nightly builds from that tag or not. if you specify a branch as the release tag, then the tarball resulting from a checkout from that tag might have a different md5 hash than the hash from the previous tarball, in which case the new one would be kept and the release node would be changed to point to the new version (updating the file, saving the new hash, etc). additionally, the node could automatically change the version string for itself whenever a new release node from the same branch is created. maybe this should even tie into the {node_revisions} table, so the revisions tab on the release page is meaningful.

all releases should be treated the same way. it'll bloat the code and complicate things a lot if we have to maintain both old-school releases-that-aren't-nodes alongside releases-as-nodes. let's just have a massive project_update_5() that creates nodes out of all the releases in the old {project_releases} table, alters the schema, and moves all the appropriate data to the new right place. it wouldn't take up much more space in the DB, it'd just move some things into the {node} and {node_revisions} table out of {project_releases}. we'll write the project code to just deal w/ the new schema and nodes, and then all is simple and clean. yeah, that update will be extremely expensive, especially on d.o, but it only has to run once. ;)

@jaza:

In most cases, won't a project have the same taxonomy terms applied for every release? Maintaining consistent categorisation of a project for all its releases could become an annoying problem. At the very least, the project module will need to copy the term associations from the node for the previous release, over to the node for the new release (I assume that you're already planning to do this).

the possibility of defining taxonomies that apply to this node type is all i had in mind. not suggesting we do it on d.o or work on any hard-coded taxonomy support for these nodes. the kind of taxonomy i was thinking of might be something to specify if this release is urgent, security, bug fix, new features, etc. (could be a multi-select).

But perhaps we should also consider setting it up so that individual release can't have their own term associations (or, we could provide this behaviour as a configurable option for each project).

it's up to the site admin how they define the taxonomies.

Will every project still have a unique node ID?

of course. project nodes aren't going anywhere. if you read above, each release node has a pointer to a particular project.

What will happen when you access the actual project node (i.e. will you be shown a list of releases, or will you be redirected to the node for the latest release)? What will be linked to on the project listing pages - the projects, or the individual releases?

the project node in all cases. keep in mind, there's talk of a grid of all projects (rows) vs. versions of drupal's core API (columns), where each entry indicates how supported/maintained that project is with that core API version, what DBs are supported, links to download the latest stable and development release, etc (http://drupal.org/node/63491). on the project node itself, there would be a little table of links to the latest releases on all "active" branches (including development snapshot tarballs).

Since there are a lot of unaliased project nodes, many people bookmark (or even memorise!) the URLs of particular projects.

only projects that haven't been touched in weeks. in June 16, 2006, i fixed this bug. ever since, if you click on the submit button on the project edit tab (even if you change nothing else) the alias will be automatically created.

It will be annoying to have to update your bookmarks (or your memory) every time a new release comes out for a project.

not the plan at all. release nodes don't replace project nodes. project nodes (and other things) can now display release nodes, that's all.

hope that clears up the proposal. any other potential objections?
thanks,
-derek

@bjvetter: that's exactly what i said in #9 above:
the possibility of defining taxonomies that apply to this node type is all i had in mind. not suggesting we do it on d.o or work on any hard-coded taxonomy support for these nodes.

project.module has no buisness requiring such a taxonomy on release nodes. i'm not even sure we'd want one on drupal.org. i'm just saying the possibility of doing so would exist. ;) and no one's proposing that these release taxonomies (if any) had anything to do with project taxonomies.

so, i think everyone's in full agreement on all this taxonomy stuff. sorry if the inclusion of any of this in the above proposal caused needless confusion about what i'm planning.

thanks,
-derek

merlin and myself are now implementing this. he ended up creating a new issue for it (which is probably for the best, so we can focus on the patch and implementation details itself, without all this background about why we want it). marking this one as a duplicate in favor of http://drupal.org/node/83339.

http://drupal.org/node/94000
ahh, one of the happiest "fixed" follow-ups i've ever made... ;)

thanks for the feedback, but no, this definitely wasn't the right place. ;)
see http://drupal.org/node/94000#feedback for the recommended places.

however, these are also duplicate... ;)

a) since they're nodes, releases already can have comments enabled if you want that on your site's installation of project.module. we consciously choose not to do so on drupal.org since there are already so many channels for user feedback (issue queue, forum posts, mailing lists, etc), that we didn't want to give project maintainers another place to have to look.

b) rating/reviewing projects is a frequently discussed idea. here's the issue for that:
http://drupal.org/node/77976

thanks, anyway...
-derek