make release node form smarter when editing HEAD releases
dww - October 17, 2006 - 11:47
| Project: | CVS integration |
| Version: | HEAD |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | dww |
| Status: | active |
Description
when project maintainers edit a release node that's got "HEAD" as the tag, it's a special case that needs some more brains. we want to keep the basic version info the same (so issues in the issue queue don't jump, etc), but allow project maintainers to change the tag to point to another branch that has the same version info. here's the idea:
- say HEAD is where the author is porting to 5.x.
- the release node pointing to HEAD says it's compatible with 5.x, major==0, and the version string is "5.x-0.0-dev".
- maintainer finally adds a DRUPAL-5 branch
- now, they want to get nightly snapshots on this branch, but they can't just add a new release since the version #s will conflict. moreover, we *want* all existing issues pointing to this particular rid to keep pointing here, we just want this release node to start using a new branch for the snapshot packages.
- maintainer should be able to edit the release, and instead of "CVS Tag" just being fixed at HEAD with no other options, the form should be smart enough to figure out from the {cvs_tags} table that the DRUPAL-5 branch is compatible with 5.x and has 0 as the major version. so, both "HEAD" and "DRUPAL-5" should be options.
- once this release node has been saved with "DRUPAL-5" as the tag, instead of HEAD, the maintainer should now be able to add a new release node pointing to HEAD with a different version (either 5.x-1.0-dev, or 6.x-0.0-dev".
make sense? ;)
-derek
#1
whoops, i lost track of this issue and ended up submitting http://drupal.org/node/90716 as a duplicate. it's got a little more text in case you're confused by what i'm talking about here. ;)
#2
first, we're now using "1.x-dev" as the version string for releases pointing to branches, don't be confused by the examples in the original post. ;)
a few additional things we need here:
#3
this is exactly what i'm after. i'd love to be able to provide a users a 5.0 release without having to branch the code and double the number of commits to keep them in sync.
#4
bumping to critical, since now that 5.x is out, a lot of folks should be moving their HEAD releases to point to DRUPAL-5 branches, and/or DRUPAL-5--2 branches. this patch doesn't address the points i raised in comment #2, but it's definitely a start. it works for the case of HEAD nodes that have a real version string, where a branch has been added which maps to the same version string. yes, we should fix the stuff from #2, too, but even committing/installing this would be a plus. tested on s.d.o (though, unfortunately, the scratch cvs repo doesn't work there ever since killes moved the s.d.o DB to another DB server). so, i had to fake it by manually stuffing tags/branches into the DB using direct db_query() calls from a php-filtered node...
#5
slightly simplified the code and added some comments.
#6
i just committed the patch from comment #5 to HEAD and DRUPAL-4-7--2, and installed on d.o.
setting this issue back to active so we can tackle part 2: the stuff i mentioned in comment #2.
#7
high 5. it works great.
#8
cool, thanks, drewish.
actually, this "part 2" stuff is less critical, so i'm dropping the priority.
#19
Regarding the remainder of this feature request…
Even if we fix this issue with code, there is still the problem that most HEAD releases with no Drupal core compabilitiy specified were created when they were D5 compatible (or earlier). But most of these projects also have 5.x-1.x-dev releases.
So those maintainers are stuck with 3 bad choices:
I know most maintainers are choosing #3 (many without even being aware of the other options.) But #2 is the only good long-term solution that I know of.