Add 8.x to Drupal project version dropdown

Posted by catch on September 2, 2009 at 2:25pm

10 followers

Issue Summary

As we head towards code freeze, some big patches which aren't that active are obviously going to have to be pushed back to Drupal 8. In the past (all of D5 and nearly all of D6) the way to do that was to mark them postponed - but that means going and finding them again when code thaw starts again and changing status, which is all a bit of a mess.

So I suggest we add a 8.x-dev version to the Drupal project, and push major API changes which aren't code freeze exceptions by any yardstick there. Then they can stay critical / cnr / cnw etc. and we pick them up again when D7 is out.

Comments

#1

Posted by webchick on September 2, 2009 at 10:08pm

Title:	Add 8.x to version dropdown	» Add 8.x to Drupal project version dropdown
Project:	Drupal core	» Drupal.org infrastructure
Version:	7.x-dev	» <none>
Component:	other	» Other

I think this is a great idea, but I'm not sure how to add such a drop-down without branching. Moving to D.o infrastructure to see if that's possible.

#2

Posted by Michelle on September 2, 2009 at 10:38pm

What about using a tag until it can be branched?

Michelle

#3

Posted by Gábor Hojtsy on September 3, 2009 at 5:32am

Well, we had a 7.x version before 7.x was branched as far as I can remember. I was trying hard to find the issue where it was added, but did not manage. My assumption is that it was added into the DB and then corrected later to point to the right release when the project was actually branched, but that sounds scary :)

#4

Posted by mike booth on September 3, 2009 at 10:16am

+1 to the idea. And it is much better, if at all possible, to use the actual 8.x version number in the dropdown than to use a hack, like tags. Otherwise, what is supposed to go into that version field? It certainly should not remain as 7.x.

The more degrees of freedom you give us, the more things will get misfiled...

#5

Posted by kiamlaluno on September 4, 2009 at 12:25am

Would not be possible to add code in drupalorg.module for this task? I guess that to be able to set an issue for a Drupal version that doesn't exist is something that will be required for Drupal 8.x, 9.x, 10.x, etc...
Rather than trying to remember how the task was accomplished the previous time, it would be useful to have a module that does it when needed (i.e., it should implement a menu callback that can be used from the person with the right role).

#6

Posted by Pasqualle on September 9, 2009 at 4:27pm

#156247: make a 7.x-dev version for the core issue queue?

#7

Posted by dww on September 9, 2009 at 5:01pm

Category:	bug report	» feature request
Assigned to:	Anonymous	» dww
Status:	active	» fixed

Yeah, the hack is that you just make a release node for core with a dummy CVS branch. Not something most users can do, but folks with "administer projects" can do it. Here are the steps in case I'm hit by a bus before someone needs to create the 9.x-dev dummy release. ;)

Add a new "8.x" term to the "Core compatibility" vocab at http://drupal.org/admin/content/taxonomy/6/add/term (or wherever that page is moved in D7)
Add a dummy CVS tag for core. In this case, I just did this from the mysql prompt:
INSERT INTO cvs_tags (nid, tag, branch, timestamp) VALUES (3060, '_HEAD_', 1, UNIX_TIMESTAMP());

In fact, we can just leave that dummy tag in there, so this step probably won't be needed in the future...
Add a release node pointing to this branch at http://drupal.org/node/add/project-release/3060 -- the version string will be all fubar when you first create it, since it's going to be confused by the non-standard CVS branch name, but that's okay -- you'll fix it before it's published. Just save the node and leave things broken for now.
Edit the new unpublished release node. If you have "administer projects" perms, you'll be able to tweak all the version string related fields. For this dummy core release, you want the following:
Title

drupal 8.x-dev

Version string

8.x-dev

Major

8

Minor

(empty)

Patch level

(empty)

Extra identifier

dev
Make sure everything looks cool peachy, then publish the node