Support contrib semver releases

Applied issue template.

Note that the patch position wouldn't exclusively be for smallish non-feature releases; it would be for any release that only contains bugfixes and no new features. I updated the usage examples.

any motion for this?

I'm currently in this situation where i can't really push a minor release and simply i should be able to use 8.x-1.0.1 as a tag!

Release naming conventions

Postponing per #1612910: [policy, no patch] Switch to Semantic Versioning for Drupal contrib extensions (modules, themes, etc)

Adding parent and related issue from #3054391: [META] Support semantic versioning on drupal.org for contributed projects

Updating the proposed resolution to what Mixologic & I have been discussing, and attaching a draft of part of the change.

This is coming up now because modules & themes can be compatible with both Drupal 8 and 9, and the API compatibility prefix is no longer a useful requirement.

I’m currently working on #3087220: Migrate project_release_supported_versions to store “branch” instead of API/Major, and #3085041: Drupal core 9.x.x releases should not attach API compatibility term is helping us actually remove our dependence on API compatibility terms. Once some of the background work is done, a test contrib project that uses semantic versioning will likely be the next test of everything.

Relating 2 issues
#3074993: Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates and then after that #3100115: The update module should recommend updates based on supported_branches rather than major versions majors will happen.

I don't think we should allow the current issue to be implemented until both those are done because otherwise the core update module won't be able to handle the new releases.

Is there going to be restriction on create releases/branches for existing projects?

For instance if if there is an existing project that has a 8.x-1.x branch with a 8.x-1.0 release when have semantic versioning tag/releases for contrib will they have to jump to the next major?

So are would prevent the above project from making a 1.0.0 release?

#15 - Yes, we will need to implement that restriction. Since Drupal.org’s Composer endpoint already translates 8.x-x.y version numbers into semver, we’ll be treating the new semantic version numbers as a continuation.

Update issue summary to reflect that issues mentioned here must be finished #3009338: [META] Support semantic versioning for extensions (modules, themes, etc) in Drupal core, and allow modules to be compatible with Drupal 8 and 9 at the same time

The child issues are now reasonably complete for the known work to do. #3104912: Swap storage of version minor & patch is the next issue in the critical path. Then #2189131: Update DrupalorgVersioncontrolLabelVersionMapperGit for semantic versioning in contrib to allow making a test project with semver releases to exercise everything for real. The rest have some interdependencies, but mostly don’t block each other.

Add note to issue summary on how to enable this for all projects toward the end of the process.

The key work here is done, we can now selectively allow projects to have semantically-versioned releases. https://www.drupal.org/project/semver_example is an example. This lets us test everywhere these releases are processed & displayed.

For core, #3100115: The update module should recommend updates based on supported_branches rather than major versions majors can have more confidence in writing test fixtures, since https://updates.drupal.org/release-history/semver_example/current has been updated.

For Drupal.org, the next priority is getting the semver releases installable via Composer, #3104693: Get packages.drupal.org ready for semver. Once that is done, making sure localize.drupal.org is working well, #3091062: Package translations for semantically-versioned contrib releases & #3069715: ftp.drupal.org has fallback regex's that need to account for semver. are high on the list. And of course, more cosmetic issues like #3111408: Make sure semver releases can show on project page.

Once there is enough support, we can open up semantic versioning to all contrib projects. With clear documentation that semantically-versioned releases will not work as well before Drupal 9, 8.9, or however far support can be back-ported.

Where should I see the semantic version with the semver_example project? Is it on admin UI only?

@Pasqualle view all releases.

adding nooks and crannies for semver support.

Updating the issue summary to categorize the remaining child issues.

We’re pretty close to being capable of enabling this for all projects. The semver_example module is installable via Composer, #3104693: Get packages.drupal.org ready for semver remains open for some double checking on edge cases. #3091062: Package translations for semantically-versioned contrib releases is working well, likely only needs some final UI work put in place.

we can now selectively allow projects to have semantically-versioned releases

I'm currently holding projects I managed from back from D9 support pending semver compat.

What can I do to opt-in and test work to date?

I'd like to be able to provide advice and direction to consumers, and project dependents.

If this is the place, projects I'd like to 🐹 guinea pig are date_recur + smsframework.

Good work guys, I'm on the edge of my seat ;)

From a Drupal.org perspective, we are ready to enable for all projects. I think Drupal core may be ready after the recent releases.

Last week, I updated https://www.drupal.org/node/1015226#semver-transition to explain the transition. I think the key part to communicate will be:

When your project switches to using semantic versioning, you must increment your major version. For example, if the latest release is 8.x-3.5, your next stable release will be 4.0.0

And I need help filling out:

If your project supports Drupal 8.TODO or lower, don’t switch to semantic versioning.

That said, I think it is okay to enable for these two projects, and https://www.drupal.org/project/twig_tweak which will have D9-only releases.

I confirmed with core maintainers this is not ready for all projects, #3009338: [META] Support semantic versioning for extensions (modules, themes, etc) in Drupal core, and allow modules to be compatible with Drupal 8 and 9 at the same time still has a must-have issue that needs to be completed, and some issues need triage.

If your project supports Drupal 8.TODO or lower, don’t switch to semantic versioning.

That is provisionally Drupal 8.8.3.

These projects can now make releases with semantic versioning:

• https://www.drupal.org/project/smsframework
• https://www.drupal.org/project/date_recur
• https://www.drupal.org/project/twig_tweak

As of https://www.drupal.org/project/cdn/releases/8.x-3.4, the CDN module only supports Drupal >=8.8. (https://www.drupal.org/project/cdn/releases/8.x-3.3 supports Drupal 8.7.x too.)

Note that it also still has a Drupal 7 branch that is supported, with the latest release being https://www.drupal.org/project/cdn/releases/7.x-2.10.

I'm happy to also be a guinea pig with the CDN module if you are looking for more testers. There already is an issue for a 4.x version with an outline of what would be different with the previous major version: #3103682: CDN module 4.x: no new features + drop BC layers + drop now irrelevant headers + PHP >=8.1 + Drupal >=9.4.

https://www.drupal.org/project/cdn can now make releases with semantic versioning.

With #3089291: Group issue version “series” by branch instead of API compatibility now done, there is currently only one minor UI update for Drupal.org remaining, #3115728: Project Documentation forms need to allow for semver.. The rest is cleanup that no one will notice, if it goes well.

Core still needs some work for support: #3009338: [META] Support semantic versioning for extensions (modules, themes, etc) in Drupal core, and allow modules to be compatible with Drupal 8 and 9 at the same time

I have just published the first semantic release of Twig Tweak. Everything works well. You have done great work. Thanks.

Works for me https://www.drupal.org/project/twig_tweak/releases/3.0.0-beta1

Thanks @drumm, works great! First release created for https://www.drupal.org/project/date_recur.

Bring on the compatibility tables! 😬

Actually, I think the majority of that could be handled automatically by #3121281: Add Drupal core compatibility info to release & project pages.

This is now enabled for all projects! Details on how to number your next version are at https://www.drupal.org/node/1015226#semver-transition. The short version is:

• If your project supports Drupal 8.8.3 or lower, don’t switch to semantic versioning.
• When your project switches to using semantic versioning, you must increment your major version. For example, if the latest release is 8.x-3.5, your next stable release will be 4.0.0

There are still core issues relating to semantic versioning, since places like update status now have multiple upgrade paths to consider. Help fix those issues at #3009338: [META] Support semantic versioning for extensions (modules, themes, etc) in Drupal core, and allow modules to be compatible with Drupal 8 and 9 at the same time

These three projects are using semantic versioning now, and are good examples for helping with those core issues:

• https://www.drupal.org/project/semver_example
• https://www.drupal.org/project/twig_tweak
• https://www.drupal.org/project/date_recur

This is now enabled for all projects!

Cool. I think the CR needs to be updated and published.

I think the CR needs to be updated and published.

I forgot I wrote that. Done: https://www.drupal.org/node/3108648

Great stuff. I tried this for og_members_tab, but i can't set my 1.x dev version to supported(here). Is this a bug or a voluntary but undocumented change?

@geek-merlin: See #3125239: Suggest 1.0.x as the first branch to create instead of 1.x and this thread: https://drupal.slack.com/archives/C1BMUQ9U6/p1586963356133500

@TR Thanx a bunch!

Many releases have been made using semantic versioning, and I’ve completed the cleanup issues. We can call this done now!

Woohoo! Thanks!