Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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_term
needs 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