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.
- Update Status module - tested in #42
TestbotPackaging scripts - tested in #62Distro packaging - uses drush makeThe release node validation code that prevents you creating releases against invalid tags/branches- tested in #62Release history XML feed generation - tested in #63Proper display of releases on the Drupal core project page- tested in #87- Proper display of The Right Core Release(tm) on prominent places where core download links are shown:
Git deploy moduleno 8.x versionMigration path for issues pointing to 8.x-dev, to point to 8.0.x-dev instead?- Localize.drupal.org
- l10n_update and equivalent core functionality in Drupal 8
Security.drupal.orgdoesn'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-branchCreate 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
- Documentation that mentions 8.x branch
- like sub pages of https://www.drupal.org/new-contributors
- ?
The future
Comment | File | Size | Author |
---|---|---|---|
#93 | 8.make_.txt | 55 bytes | drumm |
Comments
Comment #1
klonosSorry, 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?
Comment #2
dawehner@klonos
This is already done automatically:
Comment #3
dwwAdded 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.
Comment #4
dwwI just found /start as another place like /download that needs to be considered, and started a sub-list for that item to collect others...
Comment #5
klonos@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?
Comment #6
webchickAdding 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. :\
Comment #7
cosmicdreams CreditAttribution: cosmicdreams commentedolder Drupal downloads could be moved to a /legacy page that simply lists the most recent build for each of those builds.
Comment #8
klonos...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).
Comment #9
drummI 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.
Comment #10
drummCorrect issue: #2173779: Update DrupalorgVersioncontrolLabelVersionMapperGit for semantic versioning in Drupal 8
Comment #11
drumm#586146: [policy, no patch] Decide if and how to implement semantic versioning for Drupal 8.x says
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?
Comment #12
webchick#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.
Comment #13
drummTo 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.
Comment #14
webchickThat'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.
Comment #15
webchickOh, 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.
Comment #16
webchickHopefully this point is adequately addressed now. Tentatively moving back to active. Thanks so much for looking into this!
Comment #17
webchickAlso 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.
Comment #18
drummI 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.
Comment #19
webchickAdded Git Deploy module.
Comment #20
webchickNeil 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?
Comment #21
Dustin@PI CreditAttribution: Dustin@PI commented"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].
Comment #22
drummI 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.
Comment #23
drummThis 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.
Comment #24
webchickI wasn't able to do the git clone in #22 to test this further:
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.
Comment #25
drummThanks, 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?
Comment #26
webchickI 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.Comment #27
webchickOk, 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.
Comment #28
webchickThis is a more apt status.
Comment #29
drummComment #30
tvn CreditAttribution: tvn commentedHi 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!
Comment #31
ergonlogicI'll be working on this under the auspices of the Drupal Association. See: https://association.drupal.org/content/discovery-process-supporting-drup...
Comment #32
drummUpdating 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.)
Comment #33
catchComment #34
Gábor HojtsyComment #35
ergonlogicI'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.
Comment #36
webchickIs 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.
Comment #37
webchickCreated 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
Comment #38
jthorson CreditAttribution: jthorson commentedPlease 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.
Comment #39
drumm#2163683: PIFT/PIFT communication broken by D9 requeued patch looks like the best issue for #38.
Comment #40
drummComment #41
ergonlogicWe'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:
git remote add semver ssh://ergonlogic@git7.devdrupal.org:2020/project/drupal8.git
git tag 8.0.0-alpha1 && git push --tags
!major%minor%patch#extra
define('HISTORY_ROOT', '/var/www/git-dev.drupal.org/htdocs/files/release-history');
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.)drush release-create-history drupal8
drush dl --source=https://drupal:drupal@git7site.devdrupal.org/sites/default/modules/ergonlogic/project/release/project-release-serve-history.php?q= drupal8-8.x
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 (inupdatexml_get_url()
, atcommands/pm/release_info/updatexml.inc +459
)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
const UPDATE_DEFAULT_URL = 'https://drupal:drupal@git7site.devdrupal.org/sites/default/modules/ergonlogic/project/release/project-release-serve-history.php?q=';
incore/modules/update/lib/Drupal/update/UpdateFetcher.php +22
$url .= $name . '/' . \Drupal::CORE_COMPATIBILITY;
inbuildFetchUrl()
atcore/modules/update/lib/Drupal/update/UpdateFetcher.php +82
.const VERSION = '8.0.0-alpha1';
incore/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.
Comment #42
ergonlogicIt 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).
Comment #43
drummGreat 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.
Comment #44
webchickWow, that's fantastic! :)
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.
Comment #45
drummAdding #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.
Comment #46
drummThis 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.
Comment #47
webchickUgh, 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.
Comment #48
drummNo, 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.
Comment #49
webchickGot it! Ok, that seems acceptable then. Thanks.
Comment #50
drummOrganizing 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.
Comment #51
drummWe 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 like8.x-1.x
, the best thing to do is:After
8.0.x
is branched, switch back to8.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.
Comment #52
isntall CreditAttribution: isntall commented@drumm That sounds like a good plan.
Comment #53
webchickAccording 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.
Comment #54
webchickAlso, 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?
Comment #55
YesCT CreditAttribution: YesCT commentedthis 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.
Comment #56
drummSee 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.
Comment #57
webchickHm. 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. :(
Comment #58
catchIf we completely delete all the code except the README, then there's no chance of patching against it though.
Comment #59
webchickYeah, 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. :(
Comment #60
drummI'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.
Comment #61
jthorson CreditAttribution: jthorson commentedHmmm ... 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.
Comment #62
drummjthorson - 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.
Comment #63
drummRelease history is at https://git7site.devdrupal.org/files/release-history/drupal/drupal-all.xml.
Comment #64
drummI added the most recent comment that has tested functionality to the issue summary.
Comment #65
drummComment #66
drummWell, 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.
Comment #67
drummComment #68
webchickI 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.
Comment #69
webchickTalked 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.
Comment #70
catchBest 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.
Comment #71
drummBranching 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.)
Comment #72
drumm8.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.
Comment #73
drumm8.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
Comment #74
drummTestbots are confirmed working well, and issues are being moved.
Comment #75
drummCrossing out a few things confirmed working in production.
Comment #76
drummComment #77
drummHere 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.
Comment #78
hass CreditAttribution: hass commentedWhat is the plan for contrib?
Comment #79
jthorson CreditAttribution: jthorson commentedCurrently, 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.
Comment #80
mparker17@hass, @jthorson the issue to discuss semantic versioning in contrib is #1612910: [policy, no patch] Switch to Semantic Versioning for Drupal contrib extensions (modules, themes, etc)
Comment #81
drummComment #82
Gábor HojtsyIs 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
Comment #83
xjmSee also #2313917: Core version key in module's .info.yml doesn't respect core semantic versioning.
Comment #84
Gábor HojtsyComment #85
Gábor HojtsyOpened a release critical sub-issue at #2315849: Update status does not have tests with (semantic) Drupal 8 versions.
Comment #86
webchickUpdating 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).
Comment #87
drummI 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.
Comment #88
webchickNope. When 8.1.0 comes out, 8.0.12 is obsolete.
Comment #89
catchI 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.
Comment #90
Crell CreditAttribution: Crell commented#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.
Comment #91
drummCrossed that off the list in the issue summary.
Comment #92
Gábor HojtsyAlso found #2323259: Local translation file detection is not semantic version compatible.
Comment #93
drummCrossing off
Tested Drush 6.3.0 with the attached make file.
Comment #94
YesCT CreditAttribution: YesCT commentedI 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
Comment #95
drummThis 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
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)
Comment #96
YesCT CreditAttribution: YesCT commentedwell. 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.
Comment #97
YesCT CreditAttribution: YesCT commentedadding "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.
Comment #98
webchickI am tentatively marking this as fixed. The issue summary only has three things not Xed off:
Otherwise, things seem to be working well, and have been for months. Great work, drumm et al!!