| Project: | Project |
| Version: | 4.7.x-1.x-dev |
| Component: | Releases |
| Category: | feature request |
| Priority: | critical |
| Assigned: | dww |
| Status: | closed (fixed) |
Issue Summary
once releases are real nodes (http://drupal.org/node/83339) the nightly snapshots from the end of a given branch (the "-dev" releases) could automatically rename themselves when new releases are added to that release series/branch. for example:
- you first add the DRUPAL-5 branch to your module
- you create a release node pointing to it, which thinks its version is 5.x-0.0-dev
- you add the official 5.x-0.0 release
- the 5.x-0.0-dev release should immediately rename itself to 5.x-0.1-dev
this shouldn't be that hard. basically:
- in project_release_insert(), have a check that searches for the release node with the "rebuild" bit set that's pointing to the same branch (same API compatibility and major/minor versions)
- recompute the MAX(patch-level) along this series (it's not always necessarily just the most recently added patch level that would be the highest, since contrib maintainers could be making release nodes out of order)
- set the "-dev" node's patchlevel to MAX+1, and change the title and version string fields
this would help avoid some of the confusion over what the versions should be called for these snapshots, and this way, it provides the most accurate description of what it is: code on the way to becoming the next official release from that branch.
Comments
#1
hehe, the example in the original post was from before we decided on using 1.0 for the first release, not 0.0... ;)
the example should really be:
- you first add the DRUPAL-5 branch to your module
- you create a release node pointing to it, which thinks its version is 5.x-1.0-dev
- you add the official 5.x-1.0 release
- the 5.x-1.0-dev release should immediately rename itself to 5.x-1.1-dev
#2
For the time being, I'd just name the branch releases like this:
5.x-dev for the DRUPAL-5 branch and 5.x-2-dev for the DRUPAL-5--2 branch.
This seems more logical to me than having a 5.x-1.0 release as well as a branch snapshot 5.x-1.0-dev, because the latter seems to be the pre-final code for a not yet release 1.0 .
#3
indeed. i definitely don't like the status quo on this. but, if i'm going to spend any time on it, i think i'd rather just Do It Right(tm). ;)
#4
after a discussion on IRC, we collectively decided that the original intention of this issue, automatically renaming the MAX(patch) + 1, isn't really what we want. instead, we should just call these things "*-1.x-dev", e.g. for the DRUPAL-5 branch, the snapshot releases would just be called "5.x-1.x-dev". here's why:
i think the attached patch (against the latest DRUPAL-4-7--2 branch of project and cvslog) handles all the parts of the code that matter for this. while i was at it, i made our d.o-specific code validate that release nodes pointing to HEAD *must* have "x" as the patchlevel and "dev" as the extra. review, anyone?
#5
after review from natrak in IRC, i committed this to DRUPAL-4-7--2 branch. we're just updating scratch.drupal.org now...
#6