[meta] Create a plan for implementing semantic versioning for core [#2170443] | Drupal.org

[meta] Create a plan for implementing semantic versioning for core [#2170443] | Drupal.org
Skip to search
Can we use first and third party cookies and web beacons to
understand our audience, and to tailor promotions you see
[meta] Create a plan for implementing semantic versioning for core
Closed (fixed)
Project:
Drupal.org infrastructure
Component:
Packaging
Priority:
Critical
Category:
Task
Assigned:
drumm
Issue tags:
DSWG Dev Tools Team priority
Needs issue summary update
infrastructure blocker for Drupal 8.0.0
about tags
Needs issue summary update
Issue summaries save everyone time if they are kept up-to-date. See
Update issue summary task instructions
Reporter:
webchick
Created:
9 Jan 2014 at 17:57 UTC
Updated:
8 May 2015 at 23:04 UTC
Jump to comment:
Most recent
Most recent file
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
Testbot
#2268449: Run contrib module branch tests against both dev and latest stable core branches
#2163683: PIFT/PIFT communication broken by D9 requeued patch
Packaging scripts - tested in #62
Distro packaging - uses drush make
The release node validation code that prevents you creating releases against invalid tags/branches
- tested in #62
Release history XML feed generation - tested in #63
Proper 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:
/download
/start
others?
Git deploy
module
no 8.x version
Migration 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.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
Documentation that mentions 8.x branch
like sub pages of
The future
#2268449: Run contrib module branch tests against both dev and latest stable core branches
Comment
File
Size
Author
#93
8.make_.txt
55 bytes
drumm
Comments
Comment
#1
klonos
he/him
90% Melbourne, Australia - 10% Larissa, Greece
commented
9 January 2014 at 18:09
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?
or
to post comments
Comment
#2
dawehner
German
commented
9 January 2014 at 19:54
@klonos
This is already done automatically:
Last packaged version: 7.x-3.7+21-dev
or
to post comments
Comment
#3
dww
we/he/they
commented
9 January 2014 at 20:50
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.
or
to post comments
Comment
#4
dww
we/he/they
commented
9 January 2014 at 20:55
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...
or
to post comments
Comment
#5
klonos
he/him
90% Melbourne, Australia - 10% Larissa, Greece
commented
9 January 2014 at 23:16
@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?
or
to post comments
Comment
#6
webchick
she/they
Vancouver 🇨🇦
commented
10 January 2014 at 05:53
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. :\
or
to post comments
Comment
#7
cosmicdreams
commented
10 January 2014 at 14:16
older Drupal downloads could be moved to a /legacy page that simply lists the most recent build for each of those builds.
or
to post comments
Comment
#8
klonos
he/him
90% Melbourne, Australia - 10% Larissa, Greece
commented
10 January 2014 at 16:47
...or we could simply redirect the old links to the new packages. For example redirect
to
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).
or
to post comments
Comment
#9
drumm
he/him
NY, US
commented
14 January 2014 at 23:32
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.
or
to post comments
Comment
#10
drumm
he/him
NY, US
commented
14 January 2014 at 23:32
Correct issue:
#2173779: Update DrupalorgVersioncontrolLabelVersionMapperGit for semantic versioning in Drupal 8
or
to post comments
Comment
#11
drumm
he/him
NY, US
commented
15 January 2014 at 00:58
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?
or
to post comments
Comment
#12
webchick
she/they
Vancouver 🇨🇦
commented
15 January 2014 at 01:36
#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.
or
to post comments
Comment
#13
drumm
he/him
NY, US
commented
15 January 2014 at 01:49
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.
or
to post comments
Comment
#14
webchick
she/they
Vancouver 🇨🇦
commented
15 January 2014 at 02:11
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.
or
to post comments
Comment
#15
webchick
she/they
Vancouver 🇨🇦
commented
15 January 2014 at 02:55
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.
or
to post comments
Comment
#16
webchick
she/they
Vancouver 🇨🇦
commented
15 January 2014 at 02:56
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!
or
to post comments
Comment
#17
webchick
she/they
Vancouver 🇨🇦
commented
15 January 2014 at 03:00
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.
or
to post comments
Comment
#18
drumm
he/him
NY, US
commented
15 January 2014 at 04:47
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.
or
to post comments
Comment
#19
webchick
she/they
Vancouver 🇨🇦
commented
21 January 2014 at 22:23
Issue summary:
View changes
Added Git Deploy module.
or
to post comments
Comment
#20
webchick
she/they
Vancouver 🇨🇦
commented
22 January 2014 at 22:28
Neil has provisioned
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?
or
to post comments
Comment
#21
dustin@pi
commented
27 January 2014 at 22:41
"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]
or
to post comments
Comment
#22
drumm
he/him
NY, US
commented
27 January 2014 at 22:58
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.
or
to post comments
Comment
#23
drumm
he/him
NY, US
commented
27 January 2014 at 23:11
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
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.
or
to post comments
Comment
#24
webchick
she/they
Vancouver 🇨🇦
commented
4 February 2014 at 04:33
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.
or
to post comments
Comment
#25
drumm
he/him
NY, US
commented
4 February 2014 at 04:48
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?
or
to post comments
Comment
#26
webchick
she/they
Vancouver 🇨🇦
commented
4 February 2014 at 05:03
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.
or
to post comments
Comment
#27
webchick
she/they
Vancouver 🇨🇦
commented
4 February 2014 at 05:46
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.
or
to post comments
Comment
#28
webchick
she/they
Vancouver 🇨🇦
commented
4 February 2014 at 05:48
Status:
Active
» Postponed
This is a more apt status.
or
to post comments
Comment
#29
drumm
he/him
NY, US
commented
19 February 2014 at 21:39
Issue tags:
DSWG Dev Tools Team priority
or
to post comments
Comment
#30
tvn
commented
20 February 2014 at 13:57
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:
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!
or
to post comments
Comment
#31
ergonlogic
he/him
Montréal, Québec 🇨🇦
commented
28 February 2014 at 21:05
Assigned:
Unassigned
ergonlogic
Status:
Postponed
» Active
I'll be working on this under the auspices of the Drupal Association. See:
or
to post comments
Comment
#32
drumm
he/him
NY, US
commented
3 March 2014 at 19:32
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.)
or
to post comments
Comment
#33
catch
he/him
commented
4 March 2014 at 11:17
Issue summary:
View changes
or
to post comments
Comment
#34
gábor hojtsy
he/him
Hungarian
Hungary
commented
4 March 2014 at 12:35
Issue summary:
View changes
or
to post comments
Comment
#35
ergonlogic
he/him
Montréal, Québec 🇨🇦
commented
25 March 2014 at 18:48
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.
or
to post comments
Comment
#36
webchick
she/they
Vancouver 🇨🇦
commented
23 April 2014 at 19:13
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.
or
to post comments
Comment
#37
webchick
she/they
Vancouver 🇨🇦
commented
14 May 2014 at 21:36
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
or
to post comments
Comment
#38
jthorson
commented
15 May 2014 at 17:44
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.
or
to post comments
Comment
#39
drumm
he/him
NY, US
commented
16 May 2014 at 15:52
#2163683: PIFT/PIFT communication broken by D9 requeued patch
looks like the best issue for #38.
or
to post comments
Comment
#40
drumm
he/him
NY, US
commented
16 May 2014 at 15:57
Issue summary:
View changes
or
to post comments
Comment
#41
ergonlogic
he/him
Montréal, Québec 🇨🇦
commented
16 May 2014 at 20:41
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:
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.
Create a
new 'project-core'
project: We called ours 'drupal8'.
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
Add a new semver tag:
git tag 8.0.0-alpha1 && git push --tags
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
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.
Generate new release history XML for the new project:
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');
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.)
Create new release history XML:
drush release-create-history drupal8
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
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
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
We then hacked core a bit, since we hadn't done so before pushing the code to the new project:
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
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
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.
or
to post comments
Comment
#42
ergonlogic
he/him
Montréal, Québec 🇨🇦
commented
17 May 2014 at 04:38
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).
or
to post comments
Comment
#43
drumm
he/him
NY, US
commented
27 June 2014 at 04:50
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.
or
to post comments
Comment
#44
webchick
she/they
Vancouver 🇨🇦
commented
27 June 2014 at 05:52
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.
or
to post comments
Comment
#45
drumm
he/him
NY, US
commented
30 June 2014 at 21:32
Issue summary:
View changes
Related issues:
#2227411: Commit backlink incorrectly appears when commit made to new branch
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.
or
to post comments
Comment
#46
drumm
he/him
NY, US
commented
30 June 2014 at 21:38
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.
or
to post comments
Comment
#47
webchick
she/they
Vancouver 🇨🇦
commented
30 June 2014 at 21:51
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.
or
to post comments
Comment
#48
drumm
he/him
NY, US
commented
30 June 2014 at 21:55
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.
or
to post comments
Comment
#49
webchick
she/they
Vancouver 🇨🇦
commented
30 June 2014 at 22:05
Got it! Ok, that seems acceptable then. Thanks.
or
to post comments
Comment
#50
drumm
he/him
NY, US
commented
1 July 2014 at 23:55
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.
or
to post comments
Comment
#51
drumm
he/him
NY, US
commented
2 July 2014 at 00:04
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.
or
to post comments
Comment
#52
isntall
commented
3 July 2014 at 05:25
@drumm That sounds like a good plan.
or
to post comments
Comment
#53
webchick
she/they
Vancouver 🇨🇦
commented
3 July 2014 at 05:41
According to
it's possible to rename a remote branch without deleting it. Might be worth a test on the sandbox site.
or
to post comments
Comment
#54
webchick
she/they
Vancouver 🇨🇦
commented
4 July 2014 at 10:07
Also, speaking of sandbox sites... I just read in
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?
or
to post comments
Comment
#55
yesct
commented
4 July 2014 at 13:28
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
links to
(thanks drumm for the reminder about this)
So at least we should make a list of the child, child pages from
that will need to be updated.
--------
Added a bit to the summary under deployment.
or
to post comments
Comment
#56
drumm
he/him
NY, US
commented
8 July 2014 at 00:42
According to
... 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.
or
to post comments
Comment
#57
webchick
she/they
Vancouver 🇨🇦
commented
8 July 2014 at 02:51
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. :(
or
to post comments
Comment
#58
catch
he/him
commented
8 July 2014 at 09:21
If we completely delete all the code except the README, then there's no chance of patching against it though.
or
to post comments
Comment
#59
webchick
she/they
Vancouver 🇨🇦
commented
8 July 2014 at 18:20
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. :(
or
to post comments
Comment
#60
drumm
he/him
NY, US
commented
8 July 2014 at 23:43
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
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.
or
to post comments
Comment
#61
jthorson
commented
9 July 2014 at 15:14
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.
or
to post comments
Comment
#62
drumm
he/him
NY, US
commented
9 July 2014 at 21:05
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:
. Issues can be moved there,
or
to post comments
Comment
#63
drumm
he/him
NY, US
commented
9 July 2014 at 21:11
Release history is at
or
to post comments
Comment
#64
drumm
he/him
NY, US
commented
9 July 2014 at 21:15
Issue summary:
View changes
I added the most recent comment that has tested functionality to the issue summary.
or
to post comments
Comment
#65
drumm
he/him
NY, US
commented
9 July 2014 at 23:38
Issue summary:
View changes
or
to post comments
Comment
#66
drumm
he/him
NY, US
commented
9 July 2014 at 23:44
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.
or
to post comments
Comment
#67
drumm
he/him
NY, US
commented
9 July 2014 at 23:48
Issue summary:
View changes
or
to post comments
Comment
#68
webchick
she/they
Vancouver 🇨🇦
commented
10 July 2014 at 03:50
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.
or
to post comments
Comment
#69
webchick
she/they
Vancouver 🇨🇦
commented
10 July 2014 at 04:30
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.
or
to post comments
Comment
#70
catch
he/him
commented
10 July 2014 at 08:08
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
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.
or
to post comments
Comment
#71
drumm
he/him
NY, US
commented
18 July 2014 at 23:30
Branching 8.0.x is now scheduled for July 29:
. (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.)
or
to post comments
Comment
#72
drumm
he/him
NY, US
commented
29 July 2014 at 01:03
8.1.x is now branched, released, and packaged:
Issues can now be put in the 8.1.x version, to reduce distraction from 8.0.0.
or
to post comments
Comment
#73
drumm
he/him
NY, US
commented
29 July 2014 at 16:32
Issue summary:
View changes
8.0.x is now branched, released, and packaged:
We are double checking testbots, and moving issues to 8.0.x
or
to post comments
Comment
#74
drumm
he/him
NY, US
commented
29 July 2014 at 17:30
Testbots are confirmed working well, and issues are being moved.
or
to post comments
Comment
#75
drumm
he/him
NY, US
commented
29 July 2014 at 17:51
Issue summary:
View changes
Crossing out a few things confirmed working in production.
or
to post comments
Comment
#76
drumm
he/him
NY, US
commented
29 July 2014 at 18:55
Issue summary:
View changes
or
to post comments
Comment
#77
drumm
he/him
NY, US
commented
30 July 2014 at 16:06
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.
or
to post comments
Comment
#78
hass
commented
30 July 2014 at 16:30
What is the plan for contrib?
or
to post comments
Comment
#79
jthorson
commented
30 July 2014 at 16:44
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.
or
to post comments
Comment
#80
mparker17
he/him
UTC-5
commented
30 July 2014 at 16:58
@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)
or
to post comments
Comment
#81
drumm
he/him
NY, US
commented
4 August 2014 at 19:32
Issue summary:
View changes
or
to post comments
Comment
#82
gábor hojtsy
he/him
Hungarian
Hungary
commented
5 August 2014 at 13:44
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
or
to post comments
Comment
#83
xjm
she/her
commented
5 August 2014 at 14:11
See also
#2313917: Core version key in module's .info.yml doesn't respect core semantic versioning
or
to post comments
Comment
#84
gábor hojtsy
he/him
Hungarian
Hungary
commented
5 August 2014 at 14:47
Related issues:
#2313917: Core version key in module's .info.yml doesn't respect core semantic versioning
or
to post comments
Comment
#85
gábor hojtsy
he/him
Hungarian
Hungary
commented
5 August 2014 at 14:59
Related issues:
#2315849: Update status does not have tests with (semantic) Drupal 8 versions
Opened a release critical sub-issue at
#2315849: Update status does not have tests with (semantic) Drupal 8 versions
or
to post comments
Comment
#86
webchick
she/they
Vancouver 🇨🇦
commented
6 August 2014 at 16:11
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)
or
to post comments
Comment
#87
drumm
he/him
NY, US
commented
16 August 2014 at 02:46
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.
or
to post comments
Comment
#88
webchick
she/they
Vancouver 🇨🇦
commented
16 August 2014 at 06:41
Nope. When 8.1.0 comes out, 8.0.12 is obsolete.
or
to post comments
Comment
#89
catch
he/him
commented
16 August 2014 at 11:31
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.
or
to post comments
Comment
#90
Crell
commented
17 August 2014 at 18:41
#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.
or
to post comments
Comment
#91
drumm
he/him
NY, US
commented
17 August 2014 at 19:13
Issue summary:
View changes
Crossed that off the list in the issue summary.
or
to post comments
Comment
#92
gábor hojtsy
he/him
Hungarian
Hungary
commented
18 August 2014 at 11:47
Related issues:
#2323259: Local translation file detection is not semantic version compatible
Also found
#2323259: Local translation file detection is not semantic version compatible
or
to post comments
Comment
#93
drumm
he/him
NY, US
commented
10 September 2014 at 16:15
Issue summary:
View changes
Status
File
Size
new
8.make_.txt
55 bytes
Crossing off
Distro packaging - uses drush make
Tested Drush 6.3.0 with the attached make file.
or
to post comments
Comment
#94
yesct
commented
3 December 2014 at 21:38
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
or
to post comments
Comment
#95
drumm
he/him
NY, US
commented
3 December 2014 at 21:55
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)
or
to post comments
Comment
#96
yesct
commented
3 December 2014 at 22:21
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.
or
to post comments
Comment
#97
yesct
commented
4 December 2014 at 00:49
Issue tags:
infrastructure blocker for Drupal 8.0.0
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.
or
to post comments
Comment
#98
webchick
she/they
Vancouver 🇨🇦
commented
24 April 2015 at 23:04
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!!
or
to post comments
Comment
#99
8 May 2015 at 23:04
Status:
Fixed
» Closed (fixed)
Automatically closed - issue fixed for 2 weeks with no activity.
or
to post comments
Contribution record
Child issues
#2163683: PIFT/PIFT communication broken by D9 requeued patch
#2173779: Update DrupalorgVersioncontrolLabelVersionMapperGit for semantic versioning in Drupal 8
#2267719: Drupal.org cannot support semantic versioning
#2296183: Update PIFR_DRUPAL8_CURRENTSTABLEBRANCH to 8.0.x, when it exists
#2315849: Update status does not have tests with (semantic) Drupal 8 versions
Add child issue
clone issue
Related issues
Referenced by
#1612910: [policy, no patch] Switch to Semantic Versioning for Drupal contrib extensions (modules, themes, etc)
#2267715: [meta] Drupal.org (websites/infra) blockers to a Drupal 8 RC1
#2297975: Update docs to support semantic versioning
#2312641: Require use of 8.0.x over 8.x and remove 8.x
#2476565: Better version dropdown support for semantic versioning
#2732333: Deprecate -unstable release tag
Infrastructure management for Drupal.org provided by
Need a Drupal 7 extended support partner? Consider Tag1.
News items
News
Planet Drupal
Social media
Sign up for Drupal news
Security advisories
Jobs
Our community
Community
Services
Training
Hosting
Contributor guide
Groups & meetups
DrupalCon
Code of conduct
Documentation
Documentation
Drupal Guide
Drupal User Guide
Developer docs
API.Drupal.org
Drupal code base
Download & Extend
Drupal core
Modules
Themes
Distributions
Governance of community
About
Web accessibility
Drupal Association
About Drupal.org
Drupal is a
registered trademark
of
Dries Buytaert