Reconfigure CCK HEAD for D7

I'm confused. What happened to 6.x-1.*? You're jumping immediately to 6.x-2.0? Why? To pretend you're views and Earl? ;)

If you're really not going to have a 6.x-1.* series, then we should just re-rename the HEAD release node to 6.x-2.x-dev (which will immediately alter all the issues in the queue to use that version string -- there's a level of indirection, for better or for worse). You can then move it's CVS ID to point to the DRUPAL-6--2 branch, and then make a new 7.x-2.x-dev release node pointing to HEAD. However, if you skipped 6.x-1.*, maybe you're going to skip 7.x-2.* too, and you'll want to call it 7.x-3.x-dev? ;)

If it were up to me, everyone would start over at N.x-1.* whenever N changes, but this is an area where I let up the reigns and gave maintainers freedom to do their own thing, whatever that might be.

Since you already have the 6.x-2.x-dev release node, the release node currently pointing to HEAD should probably become 7.x-1.x-dev?

FYI: Release nodes pointing at HEAD can be moved by the maintainer to the corresponding branch once it is created, and a new release node can be created pointing to HEAD. (For example: 7.x-1.x-dev is created pointing to HEAD for early 7.x development, maintainer creates the DRUPAL-7--1 branch after a while and moves the 7.x-1.x-dev release from the HEAD branch to the DRUPAL-7--1 branch, once there is no release node pointing to HEAD, a new 7.x-2,x-dev or 8.x-1.x-dev release can then be created...)

Yeah, so long as you stop trying to do special case/exceptional things, none of this would require admin intervention. The plan we discussed at DrupalCon Boston was:

a) Since the HEAD branch was already being ported to 6.x, we renamed the "HEAD" release node to 6.x-1.x-dev in preparation of a DRUPAL-6--1 branch (these "HEAD" release nodes were a special case during the conversion to the new release system -- I hated them, but they were a concession to the status quo).
b) Reorganize/rename all the files in HEAD so you're happy.
----- end of admin required work -----
c) CCK devs stabilize the port
d) CCK devs create a DRUPAL-6--1 branch
e) CCK devs edit the 6.x-1.x-dev release node, and now that the right branch exists, move the tag from HEAD to DRUPAL-6--1
f) CCK devs continue to develop new stuff in HEAD, either the initial D7 port, or 6.x-2.* if y'all were going to do new features.
g) Create a new release node pointing to HEAD with the version string appropriate for what's there (either 7.x-1.x-dev or 6.x-2.x-dev as necessary).
h) Keep coding. Once you're ready to start using HEAD for something else (6.x-2.* is done, and it's time to move to D7 porting; or D7 port is stable, time to start working on 7.x-2.* or 8.x, etc), create the branch for the permanent home of whatever you've been using HEAD for up till now (step (d) again but with new versions/branches).
i) repeat steps (e) through (h) indefinitely.
...

See http://drupal.org/node/17570#HEAD for more.

Given that y'all went awry at step (d), this plan no longer works, and once more requires admin intervention. ;) However, it's not that much work, so long as y'all can converge on a numbering scheme. If you keep changing your minds every new core version what you're going to call yourselves, this isn't going to be easy. If you just reset your major version at each version of core back to N.x-1.* (as I originally intended, and as I believe still makes the most sense), there'd be no problem in the first place. If you want to increment each time (seems dumb, but it's your decision), then plan that in advance when deciding what to call the new HEAD release node at each step (g).

I'm willing to help again, but I'd rather not keep doing this. The solution isn't to stop using HEAD entirely, it's to have a little bit of a consistent plan (at least as far as versioning is concerned) and try to stick with it. ;)

Numbered (Y.x-Z.x-dev) release nodes pointing to HEAD can be edited only if there is a corresponding DRUPAL-Y--Z branch, and then it can only be moved from HEAD to the corresponding DRUPAL-Y--Z.

What webernet said. ;) In addition to the docs mentioned above, perhaps this issue will provide a better sense of what I'm talking about:
#89699: make release node form smarter when editing HEAD releases

Obviously I am an idiot about all this :)

Not at all. It's clearly not self-evident from the UI, and this particular special case around HEAD isn't exactly the most prominent thing in the CVS docs.

Anyway, your plan will definitely work, although it's ever-so-slightly confusing to have a DRUPAL-6--1 branch with bogus code. But, at this point, that's the best solution. So long as you mark it unsupported, it shouldn't really create any problems. For some minor historical consistency, I'd create your branch from the DRUPAL-6--1-0-ALPHA tag you made. In other words:

cvs co -r DRUPAL-6--1-0-ALPHA contributions/modules/cck
cvs tag -b DRUPAL-6--1 contributions/modules/cck
rm -rf contributions/modules/cck

or, if you prefer:

cvs rtag -r DRUPAL-6--1-0-ALPHA -b DRUPAL-6--1 contributions/modules/cck

(basically equivalent, although they do the same thing via different means).

That way, at least the branch will be created from a code-base that was once known as "6.x-1.something"...

Anyway, now that you have a plan, none of this requires the CVS admins, so I'm moving this back into your queue. Hope this issue was instructive, at least. ;) If so, and you have a spare moment, please consider how you can help improve the CVS docs to help prevent others from running into similar confusion themselves.

Thanks,
-Derek

Cool, thanks! I just gave it some minor lovin':

http://drupal.org/node/267852/revisions/view/307483/310508

Otherwise, it looks great.

Thanks,
-Derek