Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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
Comment | File | Size | Author |
---|---|---|---|
#21 | Picture 1.png | 150.41 KB | soxofaan |
#5 | cvs_edit_HEAD_release.patch_1.txt | 4.37 KB | dww |
#4 | cvs_edit_HEAD_release.patch.txt | 3.74 KB | dww |
Comments
Comment #1
dwwwhoops, 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. ;)
Comment #2
dwwfirst, 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:
Comment #3
drewish CreditAttribution: drewish commentedthis 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.
Comment #4
dwwbumping 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...
Comment #5
dwwslightly simplified the code and added some comments.
Comment #6
dwwi 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.
Comment #7
drewish CreditAttribution: drewish commentedhigh 5. it works great.
Comment #8
dwwcool, thanks, drewish.
actually, this "part 2" stuff is less critical, so i'm dropping the priority.
Comment #19
JohnAlbinRegarding 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.
Comment #20
babbage CreditAttribution: babbage commentedSubscribing.
Comment #21
soxofaan CreditAttribution: soxofaan commentedIs there any progress on this issue or is it unlikely that this will be fixed?
I'm one of the maintainers who's been bitten by the problem described in #19 for the CAPTCHA module
There is a release node pointing at HEAD: http://drupal.org/node/94922 , this node was created in the Drupal 4.x-era (march 2005) by user wundo
For the moment, I'm the main maintainer of the module and I am developing mainly in HEAD.
Creating tag releases is no problem,
but as mentioned above, the release node for HEAD is now useless:
This makes that I can not offer a nightly dev tar ball of the module, which is not very stimulating for development
(e.g. see #358875: Where is 6.x-2.0-dev?)
Comment #22
drewish CreditAttribution: drewish commentedsoxofaan, open a drupal webmasters issue and have someone correct it for you. i had the same problem with imagefield, imageapi and imagecache. once it's fixed you can ignore this issue.
Comment #23
apadernoI am closing this issue, as it has been created for a release that is now not supported.