>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #147493. --> Reported by: [dww](https://www.drupal.org/user/46549) >>> <h3>Summary</h3> <p><strong>Starting with Drupal core 6.x, branches in the contributions CVS repository will <em>always</em> contain the <code>--N</code> part of the branch name, to remind people that each release series belongs in its own branch.</strong>. For example, the repository would prevent maintainers from creating a DRUPAL-6 branch. They would be forced to create a DRUPAL-6--1 branch for the 6.x-1.* release series for their contribution.</p> <h3>Background and motivation</h3> <p>It's been just over 6 months since the <a href="https://www.drupal.org/node/94000">new release system</a> went live on d.o (guess we'll have to stop calling it "new" one of these days). One of the only design decisions I was opposed to, but was forced to accept during the implementation of the system, was this special case for the branch name that corresponds with core (e.g. the DRUPAL-5 branch). This design decision continues to haunt me, and continues to confuse our maintainers.</p> <p>According to the documentation and the release system code, these branches are <em>only</em> to be used for the 1.* release series compatible with the same version of core. So, DRUPAL-5 is supposed to only be for the 5.x-1.* releases of a given contribution. If you start work on a 5.x-2.* series, you're supposed to use a different branch.</p> <p>The original justification for this special case was based on a few assumptions:</p> <ol> <li>2.* and other release branches would be very rare, obscure special cases</li> <li>Maintainers were so used to just adding that branch that they'd revolt if they had to change their practice</li> <li>Users would be too confused that the same branch of core didn't exist in contrib</li> <li>For power users, deploying sites from CVS was the best way to keep their sites up to date, and having different branches for core and contrib would be too much of a burden for them</li> </ol> <p>I'm here to argue that all of those assumptions have been proven wrong by the last 6 months of experience with the release system:</p> <ol> <li>If you look at the the top downloaded modules, a large number of them have 5.x-2.* or later releases, either as the default downloads, or at least under active development (OG, views, panels, etc).</li> <li>Maintainers already have had to under-go some changes in how they manage their code. Many are taking advantage of multiple branches of development for the same version of core, to have a safe place to add new features without tying themselves to an unreleased version of core. If anything, the special case for DRUPAL-5 is confusing and destructive for them (see below), not something that's making their lives easier and less error-prone.</li> <li>Given the release system, it seems that our users are used to deploying sites based on official releases whenever possible. When there were no official releases, deploying from CVS made sense, but these days, it seems that's becoming more rare. Also, if there was *only* ever a single branch for core and contrib, it made sense for them to match. But points #1 and #2 are already complicating life for people trying to deploy from CVS, since they can't assume the same branch across all of core and the contribs they care about, anyway. I've certainly seen plenty of evidence in the issue queues of users demanding official releases from reluctant maintainers, not complaining about the specifics of what branches the code lives on in the CVS repo.</li> <li>The <a href="https://www.drupal.org/project/update_status">update_status</a> module has already seen wide-spread adoption, and it's moving into core for D6. I've even worked out a design for a <a href="https://www.drupal.org/node/124661">command-line tool that works with update_status.module</a> to upgrade a site via CVS to the latest recommended official releases (regardless of what branches they're on) of all modules you've installed on your site.</li> </ol> <h3>Harm done by the existing special case</h3> <p>The special case for DRUPAL-5 is actively confusing people. Since I can't write code to automatically audit every commit and make sure people are committing to the right branch, there's nothing except documentation and expectations to stop people from committing all kinds of things to the DRUPAL-5 branch.</p> <p>For example, <a href="https://www.drupal.org/project/og">Organic Groups (OG)</a> underwent a long period where Moshe was developing the 5.x-2.*, and then the 5.x-3.* releases, and committing all the patches to both HEAD and DRUPAL-5. So, if a critical security bug was found in the 5.x-1.0 version, it would basically be impossible to release a 5.x-1.1 with *only* the security fix, since the DRUPAL-5 branch is now full of new features that not every OG site could necessarily afford the risk of instability to upgrade to. Luckily, the 5.x-2.* series is now stable (no new features) and the recommended version, and I just helped Moshe make a <a href="https://www.drupal.org/node/146610">clean DRUPAL-5--2 branch</a> for this release series that only has the 5.x-2.* code and bug fixes.</p> <h3>What the change would entail</h3> <p>The CVS access control scripts would forbid contrib maintainers from creating a DRUPAL-6 branch. once they port their code to the D6 API, when they're ready to make a stable release, they'd have to create the DRUPAL-6--1 branch for the 6.x-1.* series. The only changes to the extensive handbook documentation would be to simplify them and remove (or at least, deprecate into a "the way we used to do things" section) the text that had to explain this special case. In a few small ways, it would also simplify the patch for moving update_status into D6 core, since it wouldn't need to handle this special case, either.</p> <p>While I can't control what gets committed to each branch via software, I <em>can</em> enforce what branches get created in the first place. The other good news is that now's the perfect time for this change, since there's no DRUPAL-6 branch anywhere in our repositories yet. Of course, what's done is done, and the current DRUPAL-5 branches would all stay as they are -- nothing that exists now would be renamed or changed, this proposal is simply about D6 and beyond. The other good news is that this is a trivial configuration tweak to the CVS access control scripts -- making this change requires writing no new code.</p> <p>Normally, I'd list the pros and cons so folks could weigh the decision, but I honestly can't think of a single, legitimate con to this proposal. So, if someone has an objection, let's hear it. Otherwise, I'm planning to make this change to the access control scripts in relatively short time, and then work on updating the CVS documentation in the handbook soon thereafter.</p> <p>Thanks,<br> -Derek</p>