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.The API compatibility component of version numbers is making less sense and should be removed.
Drupal 8+ projects can be compatible with multiple major versions of Drupal core. And semantic versioning does not have a concept of API compatibility, #2681459: Support contrib semver releases.
To reduce future confusion, we should disallow contributed projects making 9.x-… releases.
Comments
Comment #2
drummComment #3
drummComment #5
drummThis has been deployed. It points to https://www.drupal.org/node/1068944#d9 for documentation.
Comment #6
Gábor HojtsyYay! Is it possible to implement this as a git hook as well? As it is now, people will only realise this after they create their 9.x branch and do a bunch of work there and try to publish a dev release or a tag, no?
Comment #7
KingdutchI know it’s insane to do so but this still allows 10.x and up, should that be rectified?
Comment #8
alex.mazaltovFor me it sounds restrictified.. Please clarify this:
Comment #9
Gábor HojtsyA current contributed project version number is like
8.x-1.3alpha1. A future contributed project version number will be1.3.4beta2(no Y.x component and one more number possibility for full semantic versioning). The new numbering scheme is planned to be introduced either before Drupal 9 is released or shortly after so allowing 9.x prefixed releases now would become confusing the more closer we get to Drupal 9.Comment #10
drummWe don’t want to restrict people pushing arbitrary branches and tags. For example, if someone is pushing to git.drupalcode.org as a mirror, we should accept all their branches and tags, regardless of our conventions.
Git does have the ability to have the server output messages on push, such as “go here to make this a pull request” or “git remotes are changing.” I think GitLab should allow our Git hooks to output a warning. We could even do “go here to make a release” for branches and tags that do match. That’s a separate issue we can tackle later, if needed.
Underlying this is a “Core compatibility” taxonomy, which does not have a 10.x term, so 10.x is not allowed anyway. Ideally we would not have a 9.x term, but there are already have a couple releases/etc linked to it, and we have data integrity to preserve. #3085041: Drupal core 9.x.x releases should not attach API compatibility term will remove use of it for core.