This logic will need to be changed:
// Core versions are totally different from contrib.
if ($project_node->nid == DRUPALORG_CORE_NID) {
// Core official versions can be any of the following:
// 4.7.0-beta3
// 4.7.0
// 6.18
// 7.0-unstable3
// 7.0
if (preg_match('/^(\d+)\.(\d+)(\.(\d+))?(-((unstable|alpha|beta|rc)\d+))?$/', $tag_name, $matches)) {
// Starting with version 5, we only have 2 digits, major and patch.
if ($matches[1] >= 5) {
$version->version_major = $matches[1];
$version->version_patch = $matches[2];
$api_term = $version->version_major . '.x';
}
// Prior to 5, we had all 3: major, minor and patch.
else {
$version->version_major = $matches[1];
$version->version_minor = $matches[2];
// Match 4 contains the patch level without the leading '.'.
$version->version_patch = $matches[4];
$api_term = $version->version_major . '.' . $version->version_minor . '.x';
}
// Match 6 contains the version extra without the leading '-'.
if (!empty($matches[6])) {
$version->version_extra = $matches[6];
}
}
}
The change might be as simple as adding && $matches[1] <= 7 to $matches[1] >= 5, and updating all the comments.
Comments
Comment #1
drummComment #2
drummNeither #1612910: [policy, no patch] Switch to Semantic Versioning for Drupal contrib extensions (modules, themes, etc) nor #586146: [policy, no patch] Decide if and how to implement semantic versioning for Drupal 8.x clearly says whether contrib modules will be 8.0.x-... or 8.x-...
Comment #3
drummAccording to #2170443: [meta] Create a plan for implementing semantic versioning for core,
$api_termneeds to stay$version->version_major . '.x';for 8 and above. So this change will be slightly more complex than changing the if condition.Comment #4
webchickOh neat. This looks like something even I might be able to do. :)
But how would I test this? AFAIK the dev environments do not support packaging scripts, Git, etc?
Comment #5
drummdev environments do support packaging, but tricks are needed for now. I can get someone through it, but we should be chatting on IRC.
I added a note to #2146967: [Meta] Drupal.org Development Environments for improving that. I thought there was a better issue, but can't find it. Basically, packaging needs a Git repo, so
scp -r util.drupal.org:.../drupal.git .Just the tag needs to be made on that copy of the repo; we don't care about the whole Git daemon being up and running.Comment #6
ergonlogicI posted #2189131: Update DrupalorgVersioncontrolLabelVersionMapperGit for semantic versioning in contrib as a complement to this issue to allow semver in contrib.
Comment #7
ergonlogicThe two attached patches do the following:
(1) is required principally for testing, but adds some flexibility to the release infrastructure. Currently, I am promoting my core sandbox on git7site, and then pushing tags and branches to that for testing, since I obviously don't have commit access to Drupal core.
(2) basically just applies the version-matching from Drupal versions 4 and prior to Drupal 8.
Comment #8
drummCommitted the first patch.
For the second patch, I think we want to check
>= 8, assuming we'll stick with semantic versioning for the foreseeable future.Comment #9
ergonlogicDo you mean this line?
if (($matches[1] >= 5 && $matches[1] <= 7) || ($matches[1] == 8 && $matches[4] == '')) {For Drupal 8, we already have some alpha releases that don't have semver numbering yet. So this just treats those the same as Drupal 6 and 7. It's the 'else' clause that handles semver so it should work for Drupal 8+.
Comment #10
ergonlogicComment #11
ergonlogicAlso, I'll next look at adding some BDD tests for this.
Comment #13
drummIndeed, this does look good. Since the check is written that way, we can deploy ahead of the actually branching with no regressions.
Comment #14
drummNow deployed. 8.0.x and 8.0.0-(alpha|beta)N can be branched and tagged when ready.
Comment #15
drumm