[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

One question on the issue summary, why add support for (8.x-MAJOR.MINOR.PATCH) (transitionary)? I feel like I'm missing something on how this helps either the implementation end or contrib authors - i.e. why not support legacy and fully compliant, and nothing in-between?

Re: #9 I cant think of any technical reason that we'd need (8.x-MAJOR.MINOR.PATCH). Seems like it'd be less confusing to drop the CORE_COMPATIBILITY part for the semver version strings. At one point people were really attached to that string, but I think that was years back when 6.x/7.x/8.x were all being used. With our current 7.x vs 8.x-and-onward, Im in agreement that we dont need (CORE_API-MAJOR.MINOR.PATCH) and should only add support MAJOR.MINOR.PATCH .

+1 on #9, #11.

Just re-reading my comment on #1612910-396: [policy, no patch] Switch to Semantic Versioning for Drupal contrib extensions (modules, themes, etc) to see if I disagree with myself and I don't think I do. :-)

At one point people were really attached to that string, but I think that was years back when 6.x/7.x/8.x were all being used

I may even have been one of those people, but from 8.x onwards (once we implement it) CORE_COMPATIBILITY can't be expressed in a single string any more, so it just won't work any more. Also we're not going to backport support for x.x.x to 7.x, so there's no confusion between 100% incompatible major versions.

As @mixologic pointed out one place or another... In the future it'll be possible to have a contrib release that's compatible with both Drupal 8 and Drupal 9. That's given that 9.0.0 is just 8.last without the deprecated code.

So your info file will need to be able to say something like core: ~8.6 || ~9.0. It would probably say this in your composer.json file, too. (The actual d8 version constraint would be where the API changes occurred that you're using.)

There's no way to specify that using CORE_COMPATIBILITY, other than to have two different releases.

RE: #15

Since that's not strictly related to contrib semver support in core...

Well, ~8.6 || ~9.0 is valid semver. It says you can support 8.6.x and 9.0.x, but nothing else.

So if we use semver to determine such things then we'll more-or-less automatically allow multiple majors in the core key.

'semver' doesnt "only refer to a numbering scheme", it *also* refers to the implementation library that we would use (https://github.com/composer/semver) to not only specify a maj/min/patch version, but also to express acceptable dependency constraints.

~8.6 || ~9.0 is valid semver could be more thoroughly expressed as

~8.6 || ~9.0 is valid constraint using the composer/semver library

For the purposes of discussions involving version constraints, semver, and versioning, its practical and expected to assume 'semver == the composer specific implementation of how semver is handled'.

So, for core, three of the issues listed in the issue summary are addressed by using composer semver library to parse and "handle" our constraints, and extend that library where necessary to interpret legacy version numbers. (which is what the fourth issue, #3004459: [PP-1] Fold in dependency parsing wisdom from project_composer, addresses).

The '8.x issues' filter for core issues works absolutely fine and core is already using semver, however I can see contrib projects conflicting.

For example Views already has a '5.x issues' option for Drupal 5, but if View 5.0.x gets released, that's... not going to work.

Opened a dedicated issue for drupal.org.

#2313917: Core version key in module's .info.yml doesn't respect core semantic versioning was committed which will allow modules to specify composer/semver constraints for the core dependency. It also allows specifying compatibility with multiple major core versions, for example via ^8 || ^9

It has been detailed in #3069795: [meta] Improve dependency management for extensions that we solve being able to specify patch releases and semantic versioning constraints for other modules via #3005229: Provide optional support for using composer.json for dependency metadata

so #2641658: Module version dependency in .info.yml is ineffective for patch releases and #3004459: [PP-1] Fold in dependency parsing wisdom from project_composer mentioned in the summary here have already be closed.

I also just closed #3001344: ModuleHandler::parseDependency() can deal with beta1 but not beta also mentioned in the summary because this would be fixed by using composer.json.

Update the summary to remove reference to the transitionary (8.x-MAJOR.MINOR.PATCH) numbering and list of issues.

This is not anymore a requirement for 9.0 branch or alpha or even the release. It would still be very good to have this support in 9.

related update issues and added in summary

Retitling to reflect the actual scope of work here, because there are two separate initiatives that sort of ended up being implementation details of each other. @tedbow and I are going to work on gathering all the various related core issues into the issue summary here so we can do triage on them.

Updated summary with a bunch of related issues

Doing some further triage on issues that have an obvious MSCW,

Missing issues.

Adding #3113992: The 'Update' page has no idea that some updates are incompatible which is probably a regression in 8.8.x due to this work. It's at least a should-have and possibly a must-have. Also moved one issue that was already triaged to the should-have list.

Triaging a couple more issues based on previous discussions. The optional composer.json support issue is a could-have: We're not requiring it for 9.0.x, but it's a desirable API addition for a Drupal 9 minor. Disallowing core: 9.x would have a beta deadline and would be a prereq for allowing us to deprecate the key and constant for Drupal 10.

Just cleaning up redundant text in the IS.

Untagging as beta target after discussion with @tedbow and @xjm. All child issues were reviewed and individually tagged where appropriate.

I just discovered that the documentation for https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Extension... doesn't tell us how to specify SEMVER version releases for module dependencies in an info.yml file, nor does https://www.drupal.org/docs/creating-custom-modules/let-drupal-know-abou....

Is that addressed in this META and its children or should it be another issue?

Example:

dependencies:
  - drupal:field
  - search_api_field_map:search_api_field_map (>=8.x-3.x)
  - search_api_solr:search_api_solr (>=8.x-3.x)
  - token:token

Search API Solr current is now 4.1.4. What changes need to be made to this info file?

@agentrickard Semver is not supported in dependencies in info.yml files

See #24. There are a lot of problem with the current way we parse version for dependencies. We decided we would tackle this in #3005229: Provide optional support for using composer.json for dependency metadata. So if you wanted Semver for dependencies you could use composer.json when that issue is completed.

There's only 1 "must have" left

This issue #3010334: Document how contrib hook_update_N() should be numbered now that modules can be compatible with multiple major branches and versioned semantically is closed, but from the current documentation it is still totally unclear about how to start numbering the hook_update_N() functions for modules, that use semantic versioning!

So, I created a separate issue #3485835: Standardize numbering of hook_update_N following the module semantic versioning to improve this, please take a look.

The must-haves and should-haves in the issue summary are complete and semantic versioning is supported. So, it seems to me that this can be closed. Should some or all of the child issue be moved to a new meta?

Yes, let's open a new Meta for the remaining issues.