This issue is a hard blocker to Drupal 8 being released! #2267715: [meta] Drupal.org (websites/infra) blockers to a Drupal 8 RC1

Reference the policy decision at #586146: [policy, no patch] Decide if and how to implement semantic versioning for Drupal 8.x, which as of 8.0 is going to change core to return to a 3-digit versioning scheme (8.0.1, 8.1.3, etc.). There's also a huge debate about doing a similar thing for contrib at #1612910: [policy, no patch] Switch to Semantic Versioning for Drupal contrib extensions (modules, themes, etc) with no resolution in sight, so I'd rather not discuss it here.

This issue is to figure out what all needs to be updated Drupal.org-wise in order to support this. Here are some things off the top of my head, and there are probably others. This should be fleshed out with specific sub-issues for each part.

  1. Update Status module - tested in #42
  2. Testbot
  3. Packaging scripts - tested in #62
  4. Distro packaging - uses drush make
  5. The release node validation code that prevents you creating releases against invalid tags/branches - tested in #62
  6. Release history XML feed generation - tested in #63
  7. Proper display of releases on the Drupal core project page - tested in #87
  8. Proper display of The Right Core Release(tm) on prominent places where core download links are shown:
  9. Git deploy module no 8.x version
  10. Migration path for issues pointing to 8.x-dev, to point to 8.0.x-dev instead?
  11. Localize.drupal.org
  12. l10n_update and equivalent core functionality in Drupal 8
  13. Security.drupal.org doesn't care about versions

When this issue is fixed (closed), remove the blocker tag and update #2267715: [meta] Drupal.org (websites/infra) blockers to a Drupal 8 RC1.

Version number changes:

- Leave everything 7.x and below alone.
- Rename branch 8.x => 8.0.x
- Rename release node 8.x-dev => 8.0.x-dev
- Also add branch 8.1.x
- Also add tags 8.0.1 and 8.1.0
- Add a release node for 8.1.x branch.
- Add release nodes for 8.0.0, 8.0.1, and 8.1.0.

Blockers

#2227411: Commit backlink incorrectly appears when commit made to new branch
#2173779: Update DrupalorgVersioncontrolLabelVersionMapperGit for semantic versioning in Drupal 8

D.o Deployment

Drupal.org changes for the week of 7 July to 13 July 2014 notes this might happen on Tuesday, 8 July, and/or Wednesday, 9 July 2014.

  • Branch 8.1.x, create a release, and move issues to that version.
  • Core maintainer runs: git checkout -b 8.0.x; git push origin 8.0.x and all core maintainers start using 8.0.x.
  • Set 8.0.x to be the default branch at /node/3060/edit/default-branch
  • Create a dev release node for 8.0.x.
  • #2296183: Update PIFR_DRUPAL8_CURRENTSTABLEBRANCH to 8.0.x, when it exists
  • Move 8.x issues to 8.0.x:
    $query = new EntityFieldQuery();
    $query->entityCondition('entity_type', 'node')
    ->entityCondition('bundle', project_issue_issue_node_types())
    ->fieldCondition('field_issue_version', 'value', '8.x-dev')
    ->range(0, 10)
    ->addTag('DANGEROUS_ACCESS_CHECK_OPT_OUT');
    $result = $query->execute();
    
    foreach (node_load_multiple(array_keys($result['node'])) as $node) {
      print $node->nid . "\n";
      $node->field_issue_version[LANGUAGE_NONE][0]['value'] = '8.0.x-dev';
      $node->log = 'Update version number for semantic versioning.';
      $node->nodechanges_skip = TRUE;
      node_save($node);
    }
    

Other things effected that need to be updated

The future

CommentFileSizeAuthor
#93 8.make_.txt55 bytesdrumm
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

klonos’s picture

Sorry, one question: are dev versions going to be considered bug-fix releases? If so, is the plan that with each new dev, we'll be incrementing the last digit?

dawehner’s picture

@klonos
This is already done automatically:

Last packaged version: 7.x-3.7+21-dev
dww’s picture

Issue summary: View changes

Added a few more things to the list in the summary that need to at least be checked to ensure they work, if not fixed. If I think/discover others, I'll update the list again.

dww’s picture

Issue summary: View changes

I just found /start as another place like /download that needs to be considered, and started a sub-list for that item to collect others...

klonos’s picture

@dawehner: thanx for taking the time to reply. I wasn't talking about contrib, but rather about core. Sorry I didn't make that clear. So, if 8.0 becomes 8.0.0, then dev will be 8.0.0+x-dev. Right?

webchick’s picture

Issue summary: View changes

Adding some notes/questions about a migration path in terms of project_issue, since it blows up pretty badly when you rename components, but that's possibly a different thing.

Also open question about what to do with Drupals 5 - 7. I assume we leave them as-is, but that means the code needs to allow for either 3-digit or 2-digit numbers. But if we do choose to make them 5.0.23 and so on, we need a migration path for that, too, including Git/Version Control API. :\

cosmicdreams’s picture

older Drupal downloads could be moved to a /legacy page that simply lists the most recent build for each of those builds.

klonos’s picture

...or we could simply redirect the old links to the new packages. For example redirect http://ftp.drupal.org/files/projects/drupal-7.25.tar.gz to http://ftp.drupal.org/files/projects/drupal-7.25.0.tar.gz

Otherwise, in order to make sure that there is at least one release available in the download section after we move old ones to a /legacy, we'd then need to force a new build with the new semver version (even if that build would in fact code-wise be the same as the last old).

drumm’s picture

I tried this out and found an issue: #2170443: [meta] Create a plan for implementing semantic versioning for core

Drupals 5 - 7 can and should stay as-is.

drumm’s picture

drumm’s picture

Status: Active » Postponed (maintainer needs more info)

#586146: [policy, no patch] Decide if and how to implement semantic versioning for Drupal 8.x says

Implications for contributed module authors
(fill me in)

I don't think any progress on #2173779: Update DrupalorgVersioncontrolLabelVersionMapperGit for semantic versioning in Drupal 8 can be made without knowing more. That section of code also decides if the API version, used in contrib version numbers, is 8.x or 8.0.x. Is #1612910: [policy, no patch] Switch to Semantic Versioning for Drupal contrib extensions (modules, themes, etc) the issue to watch, or does #586146: [policy, no patch] Decide if and how to implement semantic versioning for Drupal 8.x need to be re-opened to be filled out?

webchick’s picture

#1612910: [policy, no patch] Switch to Semantic Versioning for Drupal contrib extensions (modules, themes, etc) is the one to watch, yep. But IMO the semver change to core can happen regardless of what happens with contrib.

drumm’s picture

To implement this, it would be really good to know if contrib will be 8.x-whatever or 8.0.x-whatever. Changing to 8.0.x will be more work, possibly including changing existing contrib releases, or allowing both. But now is a good time to tackle that.

The second half of contrib module version numbers can stay out of scope for this issue.

webchick’s picture

That's the problem, though. They're currently hung up on debating whether or not to use Composer-style numbers which would drop the 8(.0).x entirely from the version number. But there's absolutely no consensus.

So what I would assume is they stay with the same numbering scheme, until and unless there's consensus reached in that issue to do otherwise.

webchick’s picture

Oh, and the other reason I'd like to de-couple these is a factor of time.

This issue needs to be solved in order for Drupal 8.0.0 to ship. I don't have a timeframe for that other than "sometime in 2014, hopefully," but let's be optimistic and say it ships in July or something. Back up 3 months from there, and that's when we need this change done, in order to allow ample time for QA, etc.

Contrib versioning, however, doesn't really need to be solved until:

1) At least 6 months after 8.0.0 ships where we start doing "minor" feature release (8.1.0 or 8.2.0).
AND
2) We break APIs in some way during said feature release, which we are actively trying to avoid doing.

Or, it possibly doesn't need to be solved at all. Contrib modules can easily specify a minimum (and maximum) version of core they're compatible with in their .info files. So barring some kind of miracle in the other issue, we'd just go with the assumption would be that 8.x-a.b.c always runs on whatever the latest version of Drupal core version 8 is.

webchick’s picture

Status: Postponed (maintainer needs more info) » Active

Hopefully this point is adequately addressed now. Tentatively moving back to active. Thanks so much for looking into this!

webchick’s picture

Issue summary: View changes

Also adding distro packaging to the list, since this will obviously be affected, too. This may be implied by "Packaging scripts" but IMO it's good to be explicit about it.

drumm’s picture

I un-postponed #2173779: Update DrupalorgVersioncontrolLabelVersionMapperGit for semantic versioning in Drupal 8. That change will be a bit more complex, but sticking to 8.x will keep everything else much more simple. That change is doable. When deployed, the next core release will need to match the expected format, 8.0.0-something.

The special thing about distro packaging is that it runs Drush make. Drush make and Drush need to be ready too.

webchick’s picture

Issue summary: View changes

Added Git Deploy module.

webchick’s picture

Neil has provisioned http://semver-drupal.redesign.devdrupal.org/ for poking around at this. Should be ready in about 2 hours.

Since the dev environments are not true copies of production, we will need to employ a few creative hacks a la #2173779-5: Update DrupalorgVersioncontrolLabelVersionMapperGit for semantic versioning in Drupal 8 to test what we can. We'll hit a wall eventually, though. Not sure what to do at that point?

Dustin@PI’s picture

"Migration path for issues pointing to 8.x-dev, to point to 8.0.x-dev instead?"

Not to make work, but it would be nice if (some of) the issues that are pointing to 9.x-dev went to 8.x.x-dev instead. i.e. acknowledging which ones might be candidates for minor releases. Issues like this one might be an example: #1812720: Implement the new panels-ish controller [it's a good purple].

drumm’s picture

I made a copy of the Drupal core repo, without Git hooks, for devwww:

git clone ssh://{username}@devwww.drupal.org/var/git/repositories/project/drupal.git

This is writable by the developers group, so anyone should be able to commit, branch, and tag. We need sample branches and tags for every step of semver process. I pushed the 8.0.0 tag.

Note this is not hooked up via Drupal.org's Git daemon, it is a bare repo on disk; commits won't show up in Drupal, but that's okay. The create release page just needs to see the available branches and tags on disk. All dev sites can see this repo.

drumm’s picture

The create release page just needs to see the available branches and tags on disk.

This was too optimistic, we'll have to sync those to Drupal for http://semver-drupal.redesign.devdrupal.org/node/add/project-release/3060 to see them. Creating all the branches and tags is still needed, so we have real data to test with. A list in the issue summary would be good too, so we are all on the same page on things like 8.x-dev vs. 8.0.x-dev, etc.

webchick’s picture

Issue summary: View changes

I wasn't able to do the git clone in #22 to test this further:

$ ssh webchick@devwww.drupal.org
[Notice to users, blah blah blah...]
$ cd ~
$ git clone ssh://webchick@devwww.drupal.org/var/git/repositories/project/drupal.git
Cloning into 'drupal'...
The authenticity of host 'devwww.drupal.org (140.211.10.21)' can't be established.
RSA key fingerprint is 7c:8a:ca:fe:4c:ce:85:92:b6:d5:d6:4a:f8:6d:cb:1c.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'devwww.drupal.org,140.211.10.21' (RSA) to the list of known hosts.
[Notice to users, blah blah blah...]
Permission denied (publickey,gssapi-with-mic).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

So since I'm blocked there, I took the opportunity to spell out in the issue summary what test data would be needed in terms of branches, tags, and release nodes, per #23.

EDIT: Added more context of the commands run.
EDIT #2: Derp. I can't git clone over SSH on a server where I don't have a copy of my private key. ;) PEBCAK. Works fine from localhost.

drumm’s picture

Thanks, that looks complete.

For the error message - we should probably debug it over IRC. That's a general SSH connection message, before Git really gets started. Having the command used in the paste is always useful for debugging. Were you using a different computer than you you ssh to devwww from? Have your SSH keys changed recently?

webchick’s picture

Issue summary: View changes

I got a touch further with git clone file:///var/git/repositories/project/drupal.git instead, but still get blocked when trying to rename the 8.x branch. Details in the issue summary.

webchick’s picture

Ok, drumm and I synced up in IRC. Unlike #24, the blocker in #26 seems legitimate, and unrelated to #2173779: Update DrupalorgVersioncontrolLabelVersionMapperGit for semantic versioning in Drupal 8 since there are other invalid branches like "3-11" in the list on the default branch settings page.

So basically, there are three options to proceed here:

1) Continue duct-taping the dev environment to try and get enough Git communication happening in order to proceed. (Although then that probably just gets this blocked at the next thing and repeat, so not optimal.)

2) Borrow git7site and be efficient because it is reset every day, including code changes. (It is used for BDD until there are dev VMs.)

3) Wait for dev VMs (optimistically, end of April)

The thing that makes me nervous on 3) (which is obviously the most logical choice) is that we literally have no idea how much work is sitting under these bullet points in the issue summary. It could be that it's super easy, and gets knocked out in 3 days, and there are no unexpected problems. Huzzah! Or, it could be that this touches the tip of an ice berg with its tentacles woven around every aspect of our packaging tools, release management tools, etc. (Yes, icebergs have tentacles. :P)

So I'll circle back with the D.oSWG to see how best to handle this, given these constraints. In the meantime, we can probably blow away the semver dev environment since it doesn't seem like it'll work for this after all.

webchick’s picture

Status: Active » Postponed

This is a more apt status.

drumm’s picture

tvn’s picture

Hi everyone, an update: Drupal.org Software Working Group approved 30 hour budget for a discovery process on this. We are currently looking for a contractor, who can perform this discovery. More details in the following post: https://association.drupal.org/content/discovery-process-supporting-drup...
Please let me know if you are interested to take the project on, or if you know someone who would be a great candidate. Thanks!

ergonlogic’s picture

Assigned: Unassigned » ergonlogic
Status: Postponed » Active

I'll be working on this under the auspices of the Drupal Association. See: https://association.drupal.org/content/discovery-process-supporting-drup...

drumm’s picture

Issue summary: View changes

Updating the issue summary to explicitly say Drupal 5-7 should be left as-is. We wouldn't want to break everyone's tools around those releases.

Adding localize.drupal.org and security.drupal.org integration. They have automated jobs to make sure they know about releases which exist on Drupal.org. I expect the new version numbers to pass though, but we should verify. (API.drupal.org does not have that sort of automation, so is not in scope for this issue.)

catch’s picture

Issue summary: View changes
Gábor Hojtsy’s picture

Issue summary: View changes
ergonlogic’s picture

I've begun work on this issue by tackling #2173779: Update DrupalorgVersioncontrolLabelVersionMapperGit for semantic versioning in Drupal 8, which currently has some patches for review. I've also created a sandbox copy of Drupal.org Customizations, since that's where a number of the required changes will have to take place.

To work around having to commit tags to Drupal Core for testing purposes, I've created a Drupal sandbox using the 'core' project type. On git7site, I then promote that sandbox, which allows me to push semver tags and branches, add release nodes, etc. I'll also use this sandbox to test changes required to update_status by overriding the update_fetch_url variable. The plan is to do similarly for Drush, for testing downloads, make, etc.

Since git7site is resync'd with the production environment every night, I've been doing this bit manually. I've created a sandbox of Drupal.org BDD, so as to start building tests to do this instead. These tests will then act as setup scripts for further development towards resolving this issue.

webchick’s picture

Is there an update on this? Would love to test it out, but every time I've checked the staging server either the patches aren't deployed or I'm doing something wrong.

While D8 is in no danger of coming out real soon, having a "8.x-1.x-dev" to move issues against would be hugely helpful in prepping for beta/release.

webchick’s picture

Created a critical bug in the core queue to reflect that this is a release-blocker for Drupal 8: #2267719: Drupal.org cannot support semantic versioning

jthorson’s picture

Please don't create an 8.x-1.x-dev status for issues until the testing infrastructure has been updated to support it ... I've seen situations where a single issue can completely plug the entire system due to issue version confusion.

drumm’s picture

drumm’s picture

Issue summary: View changes
ergonlogic’s picture

We'd gotten bogged down somewhat is trying to automate testing of this, but that's probably beyond the scope of this issue per se.
Here's the process for testing this that we've come up with:

  1. Fork Drupal core into a new project of type 'project-core': Doing this in Doobie is not at all obvious. In fact, just cloning Drupal core times out. We'll submit a patch to Doobie to fix that, but there isn't support for forking projects at all, at the moment. So, there's more work to do there.
    1. Create a new 'project-core' project: We called ours 'drupal8'.
    2. Clone Drupal core locally, then add the new project's repo as a new remote: git remote add semver ssh://ergonlogic@git7.devdrupal.org:2020/project/drupal8.git
    3. Add a new semver tag: git tag 8.0.0-alpha1 && git push --tags
  2. Add release validation regex to project release tab ("Custom version format string"): I'm not sure whether this is entirely necessary, but it isn't available to regular maintainers. I had to do so as user 1. The regex in question was just copied from the Drupal Core project: !major%minor%patch#extra
  3. Create a new release on the new project: You should see the tag you pushed in the earlier step. This was a bit flaky, and I had to push a couple tags before one showed up in the drop-down.
  4. Generate new release history XML for the new project:
    1. Change the path that releases are available from: in project/release/project-release-serve-history.php, we had to change a constant definition to read: define('HISTORY_ROOT', '/var/www/git-dev.drupal.org/htdocs/files/release-history');
    2. Change the path that the tarball is downloaded from: drush vset project_release_download_base_project_release "https://USERNAME:PASSWORD@git7site.devdrupal.org/" (These are just the usual http basic authentication credentials for the testing site, btw.)
    3. Create new release history XML: drush release-create-history drupal8
  5. Download the project using Drush: drush dl --source=https://drupal:drupal@git7site.devdrupal.org/sites/default/modules/ergonlogic/project/release/project-release-serve-history.php?q= drupal8-8.x
    1. The documentation in project-release-serve-history.php suggests adding a clause to the local .htaccess, but we opted to just hack Drush a bit by removing an appended slash (in updatexml_get_url(), at commands/pm/release_info/updatexml.inc +459)
    2. core-quick-drupal also works: drush qd --source=https://drupal:drupal@git7site.devdrupal.org/sites/default/modules/ergonlogic/project/release/project-release-serve-history.php?q= --core=drupal8-8.x --yes
  6. We then hacked core a bit, since we hadn't done so before pushing the code to the new project:
    1. We changed the URL that Drupal checks for updates, to const UPDATE_DEFAULT_URL = 'https://drupal:drupal@git7site.devdrupal.org/sites/default/modules/ergonlogic/project/release/project-release-serve-history.php?q='; in
      core/modules/update/lib/Drupal/update/UpdateFetcher.php +22
    2. Just as we did in Drush, we hacked the update URL code to remove an extra slash: $url .= $name . '/' . \Drupal::CORE_COMPATIBILITY; in buildFetchUrl() at core/modules/update/lib/Drupal/update/UpdateFetcher.php +82.
    3. Finally, we updated Drupal's core version to match the new tag we had used: const VERSION = '8.0.0-alpha1'; in core/lib/Drupal.php +82

So with all that, we end up with new core project and release nodes using semver naming conventions, a Drush-downloaded Drupal install based on it, that can effectively check the update status against the testing site. Note that the site's 'Available updates' page shows "Project not supported" at this point (despite changing the project's status and re-generating the XML), but we haven't yet had time to delve any further into that. Also, we haven't yet tested Drush Make using this release node as a core project, but the '--source' option can be used there too, so it should be pretty easy.

ergonlogic’s picture

It turns out that the project name 'drupal' is hard-coded in ProjectInfo::getProjectName(). Changing this to reflect the name of the forked core project (drupal8) makes the update status work properly. So it looks like the relatively small changes in #2173779: Update DrupalorgVersioncontrolLabelVersionMapperGit for semantic versioning in Drupal 8 were sufficient for the most part, and that the Update Status module, packaging scripts, release node label validation code and release history XML feed generation all Just Work (tm).

drumm’s picture

Update Status module, packaging scripts, release node label validation code and release history XML feed generation all Just Work

Great news!

I'm doing some double checking with the testing infrastructure, in #2163683: PIFT/PIFT communication broken by D9 requeued patch and #2268449: Run contrib module branch tests against both dev and latest stable core branches. So far, I haven't found any blockers, so we may be able to branch 8.0.x as early as next week, depending on the core committers' schedules. (A couple practical considerations - next week has a US holiday, I have a short week the week after due to travel.)

One thing we may want to do is move all the 8.x issues to 8.0.x. The way we usually do that type of update, properly saving the revision, would update the last updated date, so I'm sure that's not an option.

webchick’s picture

Wow, that's fantastic! :)

One thing we may want to do is move all the 8.x issues to 8.0.x. The way we usually do that type of update, properly saving the revision, would update the last updated date, so I'm sure that's not an option.

Yes, please don't do that. :) That'll just make people howl when their "my issues" page is loaded with a 18+ pages of useless updates. We have past experience that tells us this. ;)

We *do* definitely want to move all issues currently against 8.x-dev to 8.0.x-dev though. Is there any way we could just do this with (GASP!) a database query instead? Something special in Version Control API perhaps? After 8.0.x is created, 8.x-dev will officially be dead code, so there's no point in keeping that release around.

drumm’s picture

Adding #2227411: Commit backlink incorrectly appears when commit made to new branch as a blocker. When core is branched, we don't want all the issues to get commit comments again.

drumm’s picture

We *do* definitely want to move all issues currently against 8.x-dev to 8.0.x-dev though. Is there any way we could just do this with (GASP!) a database query instead? Something special in Version Control API perhaps? After 8.0.x is created, 8.x-dev will officially be dead code, so there's no point in keeping that release around.

This has nothing to do with Version Control API. The version field on issues is a text field on issue nodes. The widget is slightly special to get the version numbers in a select list; the field storage is just like any other text field. Updating the table directly no longer works in D7 because the field cache exists and helps up keep the site running well.

Probably what we can do is save the issue nodes without a revision. The next comment would pick up the 8.x to 8.0.x change.

webchick’s picture

Probably what we can do is save the issue nodes without a revision. The next comment would pick up the 8.x to 8.0.x change.

Ugh, that's definitely not ideal. :( That means in order to get an accurate picture of outstanding 8.x issues you'd need to filter to both versions, including a version that's not even there anymore.

drumm’s picture

No, the field would actually be changed and the filters would work as expected. But, nodechanges will spot the change and also mention it with the next comment.

webchick’s picture

Got it! Ok, that seems acceptable then. Thanks.

drumm’s picture

Issue summary: View changes

Organizing the deployment notes a bit. I've looked over PIFT, it looks okay. I am looking over PIFR now, it is okay so far. I will look at project_dependency too.

drumm’s picture

Issue summary: View changes

git push origin :8.x # Now, delete the 8.x branch.

We should not delete the 8.x branch. Deleting things that have been pushed to a server is discouraged. Like projects that have switched from the master branch to something like 8.x-1.x, the best thing to do is:

After 8.0.x is branched, switch back to 8.x. Make one last commit that says "Hey, this is deprecated! Switch to 8.0.x. By the way, if you want to learn about semantic versioning for Drupal, here's a URL." in README.txt.

If we want to be sure no one tries to keep using 8.x, delete everything but README.txt. I recommend waiting a week or two before deleting everything, as a final "no really, we did this" notification to anyone who hasn't switched.

isntall’s picture

@drumm That sounds like a good plan.

webchick’s picture

According to http://www.benjaminlhaas.com/blog/locally-and-remotely-renaming-branch-g... it's possible to rename a remote branch without deleting it. Might be worth a test on the sandbox site.

webchick’s picture

Also, speaking of sandbox sites... I just read in https://www.drupal.org/node/2297545 that this is set to roll out next week on Tues/Wed. Awesome! :D Would you be able to post details of how to access the place where all of this is installed (including testbot) so we can QA it front to back over the weekend in advance of deployment?

YesCT’s picture

Issue summary: View changes

this will probably mean we need to change a bunch of documentation pages to mention 8.0.x instead of 8.x
like https://www.drupal.org/contributor-tasks/reroll links to https://www.drupal.org/patch/reroll

(thanks drumm for the reminder about this)

So at least we should make a list of the child, child pages from https://www.drupal.org/new-contributors that will need to be updated.

--------
Added a bit to the summary under deployment.

drumm’s picture

According to http://www.benjaminlhaas.com/blog/locally-and-remotely-renaming-branch-g... it's possible to rename a remote branch without deleting it. Might be worth a test on the sandbox site.

See the first and last comments on that post. It does rename, but that leaves every local Git clone with 8.x branches that no longer reference something in the origin repo. Keeping 8.x around, putting instructions on what happened there, gives developers more of a path forward. Instead of a Git error message when they pull, they get an update with instructions.

webchick’s picture

Hm. But an error is very visible and they can act on it. An extra text file they may or may not notice, and chances are good they'll continue making patches against old code, causing people to have to re-do work. :(

catch’s picture

If we completely delete all the code except the README, then there's no chance of patching against it though.

webchick’s picture

Yeah, that's what was suggested as a follow-up a couple of weeks later. I guess we could do it upon deployment, though.

Still very nervous that I've not been able to actually run through this entire thing front-to-back and it's going to be deployed today or tomorrow. :(

drumm’s picture

I'd rather not pull away 8.x immediately, that takes away our easy rollback plan, and doesn't give people with packaging systems, like https://www.drupal.org/tools a chance to add any '.0' they might need to. Feel free to move up the timeframe, maybe as soon as 24hr to delete the old release node and Git branch.

jthorson’s picture

Hmmm ... PIFT keys on release Nid for a lot of things ... deleting the release node could break any node_load($release_nid) logic.

I haven't looked to confirm whether this would be a red flag, or a red herring. :)

EDIT: That said, I did attempt to decouple the release_nid dependency during the D7 port. But that NID is stored in PIFTs database, and could cause issues during re-test requests, etc.

drumm’s picture

Assigned: ergonlogic » drumm

jthorson - yep, another reason to not pull away 8.x right away.

To test on git7site, I tagged 8.1.x and of course it packaged: https://git7site.devdrupal.org/node/2299363. Issues can be moved there, https://git7site.devdrupal.org/node/2270717#comment-8948056.

drumm’s picture

drumm’s picture

Issue summary: View changes

I added the most recent comment that has tested functionality to the issue summary.

drumm’s picture

Issue summary: View changes
drumm’s picture

Well, I've had zero luck contacting webchick and catch, despite a few pings back and forth. The actual branching will have to wait.

I do recommend branching 8.1.x, and creating that release, right away. Like 9.x, that will allow issues to be moved to the future version.

The 8.0.x branch should be coordinated with basic or jthorson to deploy #2296183: Update PIFR_DRUPAL8_CURRENTSTABLEBRANCH to 8.0.x, when it exists shortly afterward.

drumm’s picture

Issue summary: View changes
webchick’s picture

I can't speak for catch, but if you need to coordinate with me on something, it needs to go in my calendar, which means I need some kind of notice on when I need to be off the phone and paying attention to IRC. :) Tomorrow is pretty much all phone calls for me.

But in either case, catch is probably the best person to get with since he's the release manager. He's in UK time.

webchick’s picture

Talked about this some in IRC... what we probably need is the following people to be online at the same time to do the branching, and then stick around for 2+ hours or so to deal with any fallout:

catch (to do the branching), drumm (to debug the packaging script side of things and mass-move all of the issues to the new branch), jthorson (to debug the testbot side of things), basic (to debug any infrastructure things). I don't think I'm really needed; I offered to do QA over the weekend (and for the past several months) but it's already been deployed so there's not much value in doing that now.

Catch is in UK time, jthorson is in Mountain time and also on vacation for the next 4 days, but said he'd make himself available if he can get advance notice of when it's happening. I don't know what drumm/basic's availability is, but they're both in Pacific time.

Given these parameters, is this something the DA tech team can schedule and announce? We'll also need an announcement to g.d.o/core to tell core devs how to deal with the changes, but the core dev team can probably handle that on our end.

catch’s picture

Best times to ping me are between 10am and 4pm UK time - I'm around at other times too, but not predictably, pretty much never at 1am which looks to be when drumm tried to get hold of me last night.

I don't think we should do any branching of 8.0.x until we figure out the exact timeframe for dropping the 8.x branch - as soon as there's a commit to either branch after branching someone is going to get something wrong. Also I don't yet see a concrete answer here to updating issues from 8.x to 8.0.x automatically yet - is there a drush script or similar for that already that's been tested and is ready to go?

Not personally in a big hurry to open 8.1.x and start moving issues there - we have https://www.drupal.org/project/issues/search/drupal?project_issue_follow... to cover issues that can go into 8.X.0 but not 8.0.1 which is enough for now, none of those issues necessarily need to be ruled out from 8.0.X until much further than beta, and prematurely writing issues off for up to a year/18 months tends to demoralise people.

Alex committed a tonne of patches this week resulting in a very short and very fresh RTBC queue, this means we could have a 'commit holiday' for a couple of days while we're sorting this out without things getting out of hand - but we need to make sure all five committers know exactly when that's going to be and communicate it out to everyone else.

drumm’s picture

Branching 8.0.x is now scheduled for July 29: https://groups.drupal.org/node/434068. (It took a few emails and a call to get scheduled.)

I'll branch 8.1.x later next week. (I'm on vacation Monday and Tuesday.)

drumm’s picture

8.1.x is now branched, released, and packaged: https://www.drupal.org/node/2311455

Issues can now be put in the 8.1.x version, to reduce distraction from 8.0.0.

drumm’s picture

Issue summary: View changes

8.0.x is now branched, released, and packaged: https://www.drupal.org/node/2311847

We are double checking testbots, and moving issues to 8.0.x

drumm’s picture

Testbots are confirmed working well, and issues are being moved.

drumm’s picture

Issue summary: View changes

Crossing out a few things confirmed working in production.

drumm’s picture

Issue summary: View changes
drumm’s picture

Here is a followup for core: #2312641: Require use of 8.0.x over 8.x and remove 8.x. I think these are actions/decisions the core project should drive, not needing (much) infrastructure support.

hass’s picture

What is the plan for contrib?

jthorson’s picture

Currently, the plan for contrib is to remain with the existing 8.x-N.x format ... there's an issue floating around somewhere regarding using semantic versioning for contrib, but it didn't really approach anything resembling a consensus.

mparker17’s picture

drumm’s picture

Issue summary: View changes
Gábor Hojtsy’s picture

Is there an issue / was there an effort to add testing for semantic versions in core? Looking at update status tests, they are not even updated to 8.x versions of the update XML files (which would not be an issue if the version format would not be changing). Looked into this because I need similar coverage for #2030537: Translations not downloaded when adding a new language where localization update would use this code, and I thought *oh, update status sure has this coverage now*. Well, looks like no :D

xjm’s picture

Gábor Hojtsy’s picture

Gábor Hojtsy’s picture

webchick’s picture

Title: [meta] Create a plan for implementing semantic versioning » [meta] Create a plan for implementing semantic versioning for core

Updating title to more easily differentiate this from the other issue at #1612910: [policy, no patch] Switch to Semantic Versioning for Drupal contrib extensions (modules, themes, etc).

drumm’s picture

Proper display of releases on the Drupal core project page - 8.x isn't recommended yet

I double checked this while creating XML files for #2315849: Update status does not have tests with (semantic) Drupal 8 versions it looks great - the most recent full release (not alpha/beta) is always shown in green.

One new thing I could think of is maybe we want to recommend both 8.0.12 and 8.1.0 at the same time. I don't think we would want to do that, but want to be sure.

webchick’s picture

Nope. When 8.1.0 comes out, 8.0.12 is obsolete.

catch’s picture

I have a hazy memory of what we came up with but I think the idea was this in the case of a pending security release:

- 8.0.x gets a final release with the security fixes included.
- 8.1.0 also comes out with those security fixes.

That would allow people to update to 8.0.x immediately to get the security fixes. But then there's never another 8.0.x release after that.

However the final 8.0.x release existing doesn't mean we have to recommend it - we can just recommend 8.1.0.

Crell’s picture

#89 reflects my memory of the plan as well. There's no overlap between minor version support windows, just a dual-release when we move from one to the next.

drumm’s picture

Issue summary: View changes

Crossed that off the list in the issue summary.

Gábor Hojtsy’s picture

drumm’s picture

Issue summary: View changes
FileSize
55 bytes

Crossing off

Distro packaging - uses drush make

Tested Drush 6.3.0 with the attached make file.

YesCT’s picture

Issue summary: View changes
Issue tags: +Needs issue summary update, +blocker

I think we need to create issues for the remaining tasks here, and update the issue summary

adding blocker tag, since this blocks Drupal 8 core critical #2267715: [meta] Drupal.org (websites/infra) blockers to a Drupal 8 RC1

drumm’s picture

This needs a final round of testing for anything not crossed out in the issue summary. I think coverage for followup issues may already be complete, except

Proper display of The Right Core Release(tm) on prominent places where core download links are shown

The followup there could be more along the lines of: Prepare to make Drupal 8 look great on Drupal.org (maybe we should mention it on the home page, etc)

YesCT’s picture

Issue tags: -blocker

well. maybe a tag like
infrastrucure blocker for Drupal 8.0.0
would be better
for all things blocking d8 that are not in the core queue.

blocker is more of an internal to each queue thing.

YesCT’s picture

adding "infrastructure blocker for Drupal 8.0.0" tag, since this blocks the drupal 8 core issue: #2267715: [meta] Drupal.org (websites/infra) blockers to a Drupal 8 RC1, so that the infrastructure blockers to d8 release (in issue queues outside of the core queue) is accurate. Remove the blocker tag when this issue is fixed, and update 2267715.

webchick’s picture

Status: Active » Fixed

I am tentatively marking this as fixed. The issue summary only has three things not Xed off:

  • Localize.drupal.org (covered by other issues)
  • l10n_update and equivalent core functionality in Drupal 8 (was fixed in a core issue iirc; perhaps this one #2323259: Local translation file detection is not semantic version compatible).
  • Proper display of The Right Core Release(tm) on prominent places where core download links are shown (we won't be able to test that until Drupal 8 is the recommended release, at which point this would just be a bug fix)

Otherwise, things seem to be working well, and have been for months. Great work, drumm et al!!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.