>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #953916. --> Reported by: [dww](https://www.drupal.org/user/46549) >>> <h3>Background</h3> <p><span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/versioncontrol_project/issues/850142" title="Status: Closed (fixed)">#850142: Integrate VCAPI with project_release node add form</a></span> is a giant snake pit waiting to eat a couple weeks of my life. The current code in cvs.module is basically D4.7 era FAPI that alters a node form and conditionally turns it into a multi-step form with a variable number of steps(!). I've ported the code to D5 and D6, but never fundamentally re-wrote it or revisited how/why it works the way it does (due to time constraints during porting). I'm pretty sure I'm the only person on Earth who understands how this code works. I do <em>not</em> want to replicate this state of affairs when migrating to Git.</p> <p>Easily 50% (or more) of the complication comes from the dreaded HEAD release nodes. If you create a release node pointing to CVS HEAD, you land on an intermediate page that asks you to fill in some version information. Maintainers regularly get this wrong and end up with wonky version strings. And, there's some weirdness with validation that's allowing some people to use this to create bogus releases with duplicate version strings (see <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/project/issues/733286" title="Status: Closed (fixed)">#733286: Multiple releases nodes with the same name</a></span> for more). In fact, there's whole pile of issues in the cvs.module queue dealing with edge cases and badness of HEAD releases:<br> <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-17"><a href="https://www.drupal.org/project/cvslog/issues/89699" title="Status: Closed (outdated)">#89699: make release node form smarter when editing HEAD releases</a></span><br> <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-17"><a href="https://www.drupal.org/project/cvslog/issues/370603" title="Status: Closed (outdated)">#370603: Previewing HEAD release nodes is broken in 6.x</a></span><br> <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-5"><a href="https://www.drupal.org/project/cvslog/issues/410182" title="Status: Closed (won't fix)">#410182: Fix the UI when creating release nodes pointing to HEAD</a></span><br> ...</p> <p>Plus, there's the end-user problem of if you happen to check out from HEAD and you think that's 6.x-1.x-dev and months later, the maintainer decides to create a real DRUPAL-6--1 branch and start porting to D7 in HEAD.</p> <p>I've written entire <a href="https://www.drupal.org/node/17570">handbook pages about how to handle HEAD releases</a> given talks at numerous DrupalCons (including a Tufte-compliant <a href="https://www.drupal.org/files/maintain-release-handout.pdf">handout about managing releases</a>). In CVS, all this was sort of necessary and worth it, since it's much more of a pain in the neck to maintain multiple branches. It's much better to do all your development in HEAD and only create branches for stable release series for bug fixes and such. Plus, the way CVS handles file revision numbers, if you keep branching off branches off branches, you end up with completely bizarre revision numbers, the CVS logs get more confusing to understand, etc.</p> <p><em>However</em>, in Git, there's basically no cost of having multiple branches. Merging fixes across branches is very easy. There's no specific concept of a privileged HEAD branch (there's a default branch called 'master', but it has no special significance to Git at all).</p> <h3>Proposal</h3> <p>Once we move to Git, there shall never again be release nodes that point to 'HEAD' branches (or anything like them, 'master', etc). We already enforce that if you want an official release, you need a tag. That's staying the same (and in fact, the tags will just look like version strings, no funky mapping necessary). If you want a -dev release node, you have to create a branch that's named appropriately. See <a href="http://groups.drupal.org/node/85269">http://groups.drupal.org/node/85269</a> for more.</p> <p>This has all the following benefits:</p> <p>A) Massively simplifies the release node integration code since we no longer need the crazy intermediate page. All release nodes will have the same set of pages and steps:<br> page 0: pick a project (if it's not already in the URL)<br> page 1: pick a branch or tag<br> page 2: everything else</p> <p>B) Easier to document and understand for project maintainers.</p> <p>C) Easier for end users, since they never are tempted to checkout a generic branch that might change down the road out from under them.</p> <h3>Legacy release nodes currently pointing to HEAD</h3> <p>The one sucky thing here is that we currently have 3388 release nodes pointing to 'HEAD' somewhere. :( We need to do *something* with these. sdboyer tells me that the current plan is during the migration, 'HEAD' will be renamed to 'master'. So, that means we'd still have existing release nodes that point to 'master'. Drat.</p> <p>However, at least we won't allow *new* release nodes to point to 'master'. And, existing release nodes already know their version information. So, we could just add a special case (sort of like we have now) that allows release maintainers to move the branch a release node points to if a branch with the matching version information is available in that project's Git repo. This is a one-time operation -- you can only move from generic (HEAD/master) to specific (DRUPAL-6--1/6.x-1.x), not the other way around. So, we'd still have these legacy nodes hanging around, but at least no new ones would be created going forward, and hopefully many of them will be moved to proper branches rather quickly after the migration.</p> <p>----</p> <p>So, that's the plan. Any objections? Marking this 'major' since the outcome of this decision is blocking progress on the exploratory work I need to do for #850142 to see just how bad that task is really going to be...</p> <p>Thanks,<br> -Derek</p>