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

CommentFileSizeAuthor
#21 Picture 1.png150.41 KBsoxofaan
#5 cvs_edit_HEAD_release.patch_1.txt4.37 KBdww
#4 cvs_edit_HEAD_release.patch.txt3.74 KBdww

Comments

dww’s picture

dww
we/he/they
commented

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

dww’s picture

dww
we/he/they
commented

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:

  1. we also want to add the ability to recompute the version string on HEAD nodes, e.g. once you specify a core compatibility, you should be able to re-name the version from "HEAD" to "5.x-1.x-dev" (if that's what it now is).
  2. we need to be smarter about the core compatibility selector in these cases... if there's no term currently set, it should default to [none] and be required, as if we were on the earlier pages of the release node add form...
drewish’s picture

drewish commented

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.

dww’s picture

dww
we/he/they
commented
Version: 4.7.x-1.x-dev » 6.x-1.x-dev
Assigned: Unassigned » dww
Priority: Normal » Critical
Status: Active » Needs review
StatusFileSize
new cvs_edit_HEAD_release.patch.txt3.74 KB

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

dww’s picture

dww
we/he/they
commented
StatusFileSize
new cvs_edit_HEAD_release.patch_1.txt4.37 KB

slightly simplified the code and added some comments.

dww’s picture

dww
we/he/they
commented
Status: Needs review » Active

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.

drewish’s picture

drewish commented

high 5. it works great.

dww’s picture

dww
we/he/they
commented
Priority: Critical » Normal

cool, thanks, drewish.

actually, this "part 2" stuff is less critical, so i'm dropping the priority.

johnalbin’s picture

johnalbin
they/他
Primary language English
Location Taipei, Taiwan
commented

Regarding the remainder of this feature request…

we need to be smarter about the core compatibility selector in these cases... if there's no term currently set, it should default to [none] and be required, as if we were on the earlier pages of the release node add form.

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:

  • Mark the HEAD releases as D5 compatible. But now they are stuck: they can't move the HEAD release to the DRUPAL-5 branch since there is already a DRUPAL-5 release. And they can't create a new D6 compatible HEAD release since there is already a HEAD release. Right?
  • Mark the HEAD release as D6 compatible. And watch all the issues against the D5-version of HEAD jump to 6.x-1.x-dev.
  • Leave the HEAD release with no core compatibility value. Forever.

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.

babbage’s picture

babbage commented

Subscribing.

soxofaan’s picture

soxofaan commented
StatusFileSize
new Picture 1.png150.41 KB

Is 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:

  • it doesn't update the tarball by itself, as far as I can tell (last time I looked it was from march 2008, while there have been many commits since then)
  • I can't (re)set core compatibility or other fields (see screenshot) on the node edit form. There isn't even a single option for the core compatibility field.

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

drewish’s picture

drewish commented

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

avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented
Status: Active » Closed (outdated)

I am closing this issue, as it has been created for a release that is now not supported.