This issue is intended to be complimentary to #2173779: Update DrupalorgVersioncontrolLabelVersionMapperGit for semantic versioning in Drupal 8, though they may end up altering some of the same regexes. It's also intended to be more focused and short-term than the discussion going on in #1612910: [policy, no patch] Switch to Semantic Versioning for Drupal contrib extensions (modules, themes, etc), which is a pretty major bikeshed.

Over in the Aegir project, we'd very much like to be able to #2168955: switch to semantic versionning. We're fine with 7.x-3.x.y for the time-being, and 8.x.y-4.x.y (or whatever) down the road. In #2170443: [meta] Create a plan for implementing semantic versioning for core, webchick posted a list of places where changes may be required to support re-numbering the Drupal core version. Some subset of these will need work to support semver for contrib.

I'll post a patch shortly that allows semver for contrib in DrupalorgVersioncontrolLabelVersionMapperGit. I've also looked through Update Status module, which shouldn't require any modification for this. I'll keep working through the list, and post any relevant findings here (unless a meta issue for this is in order.)

Tasks

CommentFileSizeAuthor
#1 drupalorg-allow_contrib_semver-2189131-1.patch2.47 KBergonlogic

Comments

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
commented
Status: Active » Needs review
StatusFileSize
new drupalorg-allow_contrib_semver-2189131-1.patch2.47 KB

Patch attached.

Since, I don't have a full testing environment, I tested like so (with a couple dsm()'s):

include_once(drupal_get_path('module', 'versioncontrol_release') .'/includes/interfaces.inc');
include_once(drupal_get_path('module','drupalorg_versioncontrol').'/plugins/label_version_mapper/DrupalorgVersioncontrolLabelVersionMapperGit.class.php');
define('DRUPALORG_CORE_NID', 0);
$project_node = new stdClass();
$project_node->nid = 1984;

// Current tag
$tag_name = '7.x-3.1-alpha69';
$version = @DrupalorgVersioncontrolLabelVersionMapperGit::GetVersionFromTag($tag_name, $project_node);

// Semver tag
$tag_name = '7.x-3.1.0-beta3';
$version = @DrupalorgVersioncontrolLabelVersionMapperGit::GetVersionFromTag($tag_name, $project_node);

//Current branch
$branch_name = '7.x-3.x';
$version = @DrupalorgVersioncontrolLabelVersionMapperGit::GetVersionFromBranch($branch_name, $project_node);

// Semver branch
$branch_name = '7.x-3.1.x';
$version = @DrupalorgVersioncontrolLabelVersionMapperGit::GetVersionFromBranch($branch_name, $project_node);

While this was sufficient for this very limited component, the entire packaging system wouldn't be so easily fooled. I'll look into getting some more complete testing environment in place. A pointer towards documentation for that would be greatly appreciated.

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
commented

I grepped (via the git-web browser) the code of all the modules I could think might be relevant, looking fot the string 'version_patch'. Presumably this would be used to access the relevant data set in DrupalorgVersioncontrolLabelVersionMapperGit.

It doesn't appear in any of the following:

  • the rest of the drupalorg modules
  • drupalorg_drush
  • drupalorg_crosssite
  • apidrupalorg
  • documentation
  • infrastructure
  • project_issue
  • version_control
  • versioncontrol_git
  • project_solr
  • api
  • update_test_module
  • project_dependency
  • project_issue_file_review
  • project_git_instructions
  • doobie
  • git_deploy

Here are the places where it did come up:

  1. project_issue_file_test (though it appears to have been removed in the 7.x branch)
  2. drupalorg_testing
  3. versioncontrol_project (in a more generic class that inherits from the same interface as DrupalorgVersioncontrolLabelVersionMapperGit)
  4. D8 core (and of course similar logic appears in D6 & D7 too)
  5. Drush

I probably missed some, so feel free to post other projects I should look at. But I guess my next step is to evaluate each of the items on the latter list, and see whether they need patching to accommodate semver for contrib.

drumm’s picture

drumm
he/him
Location NY, US
commented

drupalorg_testing is not maintained.

The best way to check around the codebase is to use the actual codebase on a dev site, https://drupal.org/node/1018084. These aren't properly integrated with a Git daemon, so they aren't good for actual testing yet.

For testing, we have just have git7staging for now. This should follow after #2173779: Update DrupalorgVersioncontrolLabelVersionMapperGit for semantic versioning in Drupal 8 since that is a blocker for Drupal 8.0.0.

dww’s picture

dww
we/he/they
commented
Status: Needs review » Postponed
Parent issue: » #1612910: [policy, no patch] Switch to Semantic Versioning for Drupal contrib extensions (modules, themes, etc)

Note: aegir isn't a module and shouldn't have Drupal module versioning at all. That's yet another case for #322626: META: Package and version non-modules for download, not this.

I still don't think semver makes sense for Drupal modules, but that's to discuss at bikeshed-o-rama #1612910: [policy, no patch] Switch to Semantic Versioning for Drupal contrib extensions (modules, themes, etc), not here.

Until that's resolved, it's pointless to have this issue active, lest we risk forking the discussion/debate.

That said, thanks for the patch!

Cheers,
-Derek

drumm’s picture

drumm
he/him
Location NY, US
commented
Parent issue: #1612910: [policy, no patch] Switch to Semantic Versioning for Drupal contrib extensions (modules, themes, etc) » #2681459: Support contrib semver releases

drumm credited tedbow.

drumm’s picture

drumm
he/him
Location NY, US
commented
Status: Postponed » Active
Related issues: +#3104912: Swap storage of version minor & patch

With #3104912: Swap storage of version minor & patch almost done, I do not think this is blocked on anything.

This will be full semver option, without an API compatibility component. Legacy version numbers should still be supported, without any additions.

For Composer, 8.x-… and semver releases will be mixed in the same Composer endpoint, duplicate version numbers should be prevented. As in, if 8.x-1.2 exists, you can not make a 1.2.0 release. The whole major version used for legacy version numbers should probably be considered off-limits for semver, so there are less edge cases for version number comparison.

drumm’s picture

drumm
he/him
Location NY, US
commented
Assigned: Unassigned » drumm
drumm’s picture

drumm
he/him
Location NY, US
commented
Issue summary: View changes

Add tasks to issue summary.

  • drumm committed 5b863c4 on 7.x-3.x 
    Issue #2189131: Named subpatterns make regexps more readable?
  • drumm committed b223e0e on 7.x-3.x
    Issue #2189131: Consolidate duplicate API term loading code
  • drumm committed f3699e4 on 7.x-3.x
    Issue #2189131: Update DrupalorgVersioncontrolLabelVersionMapperGit for...
drumm’s picture

drumm
he/him
Location NY, US
commented
Issue summary: View changes
Related issues: +#3104684: Update project_composer_get_project_namespace() to handle semver releases without $api_tid

The first two tasks are done, Drupal.org now has some ability to handle contrib semver version numbers, once we enable them.

Adding #3104684: Update project_composer_get_project_namespace() to handle semver releases without $api_tid, since not having an API compatibility walks straight into this.

drumm’s picture

drumm
he/him
Location NY, US
commented
Issue summary: View changes

  • drumm committed 3addf74 on 2189131-semver 
    Issue #2189131: Prevent conflicts between 8.x-* and semver releases
  • drumm committed 5b863c4 on 2189131-semver
    Issue #2189131: Named subpatterns make regexps more readable?
  • drumm committed b223e0e on 2189131-semver
    Issue #2189131: Consolidate duplicate API term loading code
  • drumm committed f3699e4 on 2189131-semver
    Issue #2189131: Update DrupalorgVersioncontrolLabelVersionMapperGit for...
drumm’s picture

drumm
he/him
Location NY, US
commented
Issue summary: View changes
Issue tags: +DrupalCampNJ2020

“Build something to prevent conflicting versions” is ready to go now. All semver releases for a project must have a major version higher than the highest 8.x-* major version; and all new 8.x-* releases will need to have a lower major versions than the lowest semver major version.

This means if you have a fresh project and release 1.0.0, you can’t go back and release 8.x-1.0.

I also updated the issue summary with another restriction tedbow discovered we should have:

Dev releases like 1.x-dev will be allowed, but that 1.* release series should not be able to be marked as “supported” by the project maintainer. That series will only ever contain that dev release, and 1.* being supported would make update status computation unnecessarily convoluted.

  • drumm committed 3addf74 on 7.x-3.x 
    Issue #2189131: Prevent conflicts between 8.x-* and semver releases
drumm’s picture

drumm
he/him
Location NY, US
commented
Issue summary: View changes

I moved the last addition to #3110860: Allow restricting “supportable” branches

Now is a good time for version number requests for the test project.

drumm’s picture

drumm
he/him
Location NY, US
commented
Issue summary: View changes

Both #3104684: Update project_composer_get_project_namespace() to handle semver releases without $api_tid & #3110860: Allow restricting “supportable” branches are now deployed. I believe making the example project is the only remaining task.

drumm’s picture

drumm
he/him
Location NY, US
commented
Status: Active » Fixed

The example project now exists: https://www.drupal.org/project/semver_example/releases

dww’s picture

dww
we/he/they
commented

Fantastic! Great work, @drumm.

Might make sense to make myself and @tedbow maintainers for https://www.drupal.org/project/semver_example so we can tag other releases as needed for various update.module testing scenarios?

Thanks again,
-Derek

andypost’s picture

andypost
he/him
Primary language Russian
commented

Looks https://twitter.com/drupal8modules can't parse new versions

drumm’s picture

drumm
he/him
Location NY, US
commented
Issue summary: View changes

Might make sense to make myself and @tedbow maintainers for https://www.drupal.org/project/semver_example

tedbow is already a maintainer, and I’ve just added you. It is easy to opt-in a handful of projects, if we need another test from scratch.

drumm’s picture

drumm
he/him
Location NY, US
commented

Looks https://twitter.com/drupal8modules can't parse new versions

That Twitter account is in no way official. Their profile says

Maintained by @pietervanleuven. Ping me for improvements!

And the “8” in the name will become increasingly inaccurate too, anyway.

dww’s picture

dww
we/he/they
commented

@drumm:
Re: #21: Thanks!
Re: #22: Yup. ;)

Cheers,
-Derek

Status: Fixed » Closed (fixed)

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