Following #2822727: [policy, no patch] Adopt a continuous API upgrade path for major version changes, 9.x should only drop deprecated APIs from 8.x
This means that at least theoretically, 99% of 8.x modules that are not using deprecated APIs will run on 9.x.
However, the core key in .info.yml only supports a single version. To allow modules to run on two or more versions, we should allow that to take a version range. We already have versioned dependencies for modules so may be able to re-use some of that code (or at least find out why we can't).
Comments
Comment #2
catchComment #3
MixologicIt would be nice if the core key could begin to be interpreted, internally, just like any other dependency, and begin to allow the same kinds of dependency constraints as are allowed in other dependency declarations.
I would strongly suggest that fixing the dependency constraint parsing code to support semantic versioning would be a blocker to this: #2641658: Module version dependency in .info.yml is ineffective for patch releases
Comment #7
gábor hojtsyComment #8
gábor hojtsyActually this is the same as #2807145: [policy, no patch] Allow contrib projects to specify multiple major core branches, closing in favor of that. Will copy over the comment from @Mixologic.