Packaging script no longer repackages HEAD release nodes that don't know their version.

You can't edit the project node because the input format is set to Full HTML, presumably by dopry for that donate button. Talk to dopry about that. ;) I wish there was a good usability solution for this problem in core -- this has probably confused 100,000s of Drupal users around the world at one time or another.

In terms of the HEAD release node not getting repackaged... holy crap. I just debugged it and discovered that in fixing #126554: cases in edit/releases tab on project nodes: default release broken I completely forgot about the versionless HEAD release nodes (die, die, HEAD release nodes!), and changed the query in the packaging script such that it now completely ignores release nodes that don't know their Drupal core compatibility. ;) Tee hee.

Not sure if this is a feature or a bug, so I'll leave this as a 'task' for now. ;)

We have 2 options:

A) We have to revisit that stinking query and handle the evil HEAD case.

B) We announce to the world (with our handy CVS account holders newsletter) that the evil 'HEAD' version release nodes are hereby deprecated, and everyone should finally get around to following the instructions at http://drupal.org/node/267852 so we can kill the last of these nasty special cases once and for all.

To be clear, release nodes with real version strings that point to HEAD are still ok. The problem are the auto-generated release nodes that think their version is "HEAD" -- relics of a bygone era.

My strong preference is to go with option (B)...

If the evil HEAD case is a d.o specific thing (in other words, it's unlikely that another site running project* + cvslog would have release nodes that are in a similar state), then I say go with B, since one of our missions is to eliminate d.o specific code from project*. However, if other sites using the module might be in a similar situation, I don't know that we've officially deprecated such behavior in the module itself, just on d.o, and so we might want to fix the regression.

Can you run a query to find out how many releases think HEAD is the version? If it's not too many maybe we could just create issues in each of the queues reminding them that we've deprecated HEAD and pointing them to the handbook where it says how to convert. I could help with this, if necessary.

Also, since there are only a few people with the privs to actually convert an old HEAD node into a new one with the proper version information (and I'm not one of them), we need to try to be as responsive as we can to infrastructure requests asking us to do so.

Technically, this is a duplicate of #249467: HEAD release nodes out of date

I am fine with B. We need to keep moving the community (and the code) in a saner direction. We've accomplished a lot - keep it up!

B is a solid solution.

The project node problem could be because it is "Full HTML" (I believe so the image can be in it).

@drewish - Are you generally able to use the Full HTML input format?

(note to self, read all followups before commenting)

The only bummer with B is that there are still 900 HEAD release nodes associated with published projects... Oy vey.

@aclight: The packaging script is utterly d.o-specific. It's just an example to start from, anyone using all this stuff on another site will certainly need to customize it, anyway. These versionless HEAD release nodes are fairly specific to d.o, too. The whole point of project_release.module is that every release node has a real version.

Let us make things consistent and have less exception cases. So, having releases pointing to HEAD should not be allowed. If you want a release, then you have to branch, and make the branch correspond to a Drupal core version.

Regarding the published nodes, we can find out who created them and tell them on date so and so, these will go away, so they have to do something by then.

@kbahey: No, no, no. ;) Please don't raise that red herring in this discussion. I already said:

To be clear, release nodes with real version strings that point to HEAD are still ok. The problem are the auto-generated release nodes that think their version is "HEAD" -- relics of a bygone era.

Using HEAD as a branch is utterly fine. We shouldn't force people to make more branches than they need. Tons of documentation and best practices already explain how to do this properly, and by and large, I think most people are actually starting to get it. The only problem here are the original "HEAD" release nodes that don't have a version.

Please, let us stay on track with this thread.

I was hoping for more consistency. Sorry for being over eager.

@drewish: don't just bug hunmonk -- if you make an infra issue about it as described on http://drupal.org/node/267852 there are lots of folks who have been fielding these requests (merlin, greggles, myself, hunmonk, etc, etc).

@drewish -- hehe, fair enough. The problem is that even though it now knows it's compatible with 6.x core, it thinks its version is "HEAD". Do you want it to be "6.x-1.x-dev", or are you planning to call it "6.x-2.x-dev"? Personally, I think "6.x-1.x-dev" makes more sense, since it's the first release compatible with 6.x core), but Earl started a trend with views (which others seem to have adopted) to preserve the current major version even if you jump core versions. I don't have the energy or desire to lead a fight around this, so I'm just accepting reality as it is -- and maintainers will just decide their own scheme for this. So, we just need to know your plans for Imagefield, as explained in that handbook page I keep pointing you to. ;) Thanks.

Hehe, see what I mean? "Contributors gone wild" with version strings. ;) Anyway, now fixed: http://drupal.org/node/96519.

Leaving this task open while we decide what to do about the larger issue.

This may have been fixed based on #327912: Tarball stopped generating

I haven't seen this recently.