Migrate away from the use of master branch: Document and promote project moves

Zen 7.x-3.x is an example of a dev release pointing at HEAD. After the build, I'll see if it's currently possible to move them:

http://git-dev.drupal.org/node/628464/edit

It won't be possible to edit the node and change the branch it's pointing to. I never added any code in versioncontrol_release to handle this case, since I was under the impression that we'd never have HEAD/master release nodes given [ #953916] ...

Should this issue move to the versioncontrol_project issue queue, or is this a meta issue and we need another issue in vc_project to implement a work-around for this?

rfay: You can 1. cvs tag -b DRUPAL-n--n 2. Go to the release node and change the branch to DRUPAL-n--n from head (if the version works, you can change it now)

rfay: I meant on d.o. that could be a problem

Okay, see #1061592: Re-add special-case for editing release nodes pointing to master/HEAD to allow maintainers to move to a real branch for the issue to re-add this special case when editing release nodes over in the versioncontrol_project queue...

Unassigning this as I'm not working on it.

@dww: I think I remember you helping people do this shortly after the migration, and I thought there was documentation created, but I can't find it. Do you know if there are docs and if not, can you help create them?

There's no documentation about it. IMHO it's fairly self-explanatory, but of course I think so since I wrote the code. ;) I suppose we could add a page somewhere. However, I just spent about 10 minutes searching through our docs and didn't find a great place to put this. Maybe as a child of Full projects or something? I guess I'll try to find arianek in IRC and get her feedback.

This handbook page should mostly be about the best practice of not using 'master' for anything real and doing all work in a version-named branch. Then, there will be a section on the page for dealing with legacy releases still pointing to 'master' and how to move them to a version-named branch. So, perhaps this could even be a new subsection of the Release naming conventions page?

Anyway, I'm happy to generate content for this if I knew where to put it... ;)

@danmuzyka and I have been handling organization of the Git docs and arianek will probably refer you back to one of us :) If you put it beneath the Release naming conventions, I'll see he takes a look. It makes sense to me to put it there.

- edit -

Also, thank you! :)

i absolutely would ;)

See http://drupal.org/node/1127732 for sun's start on what to do with these.

Yay, that's even more useful and detailed than the draft I would have written... thanks, sun! Procrastination++ ;)

Maybe we need to flesh out his point #2 with a screenshot or something, but this is basically all there is to say about the topic.

@rfay: Absolutely, I agree that's a top priority -- it just doesn't exist yet. ;) I meant in terms of "missing documentation" we're now set (although arguably we could move that page somewhere more discoverable). As soon as #1074960 is done, we can definitely update this page and promote these moves even more vigorously.

Cheers,
-Derek

I was going to add the screencap but the Git branch isn't editable, so I'm not sure what's supposed to happen in step 2.

Got the interface figured out and the screen caps added. Thanks rfay.

For anyone else who needs to do this who finds this thread, the documentation is linked in comment #15: http://drupal.org/node/1127732