#3054391: [META] Support semantic versioning on drupal.org for contributed projects deals with all the things Drupal.org needs to support if/when Drupal extensions support semantic versioning. A possible alternate track is that Drupal core will only support extensions to specify multiple core compatibility (eg. Drupal 8 and 9 at the same time).
Drupal.org and related project currently assume that core compatibility is connected to version number(8.x- prefix) and branch name. For example in project listing extension compatibility based on branch naming, one cannot filter to projects with Drupal 9 compatibility if that information is not in the project version number but in the package/repository content only. This affects project listings at least.
Ideally Drupal core supports semantic versions and Drupal.org supports semantic versions. This is still to be done in that case as a subissue of #3054391: [META] Support semantic versioning on drupal.org for contributed projects. However if not the full scope of that is done and we keep the 8.x versioning for 9.x projects we still need to do this.
Issues that should be resolved:
Related core issues without a direct non-core issue
TBD.
TBD.
TBD.
N/A.
Comments
Comment #2
gábor hojtsyComment #3
xjmComment #4
tedbow#2313917: Core version key in module's .info.yml doesn't respect core semantic versioning was committed with allows multiple core functionality in contrib projects
un-Postponing this
Comment #5
gábor hojtsy#2313917: Core version key in module's .info.yml doesn't respect core semantic versioning landed. I opened #3078111: Project browsing/search compatibility filter should work off dependency data as a new child of this.
Updated issue summary.
Comment #6
drummProjects on Drupal.org don’t actually have core compatibility. They have releases, which have core compatibility.
Our implementation idea for semantic versioning for contrib, #2681459: Support contrib semver releases/#3054391: [META] Support semantic versioning on drupal.org for contributed projects, was to set the core compatibility field to NULL. Core’s usage of Drupal.org APIs needs to move over to not-core-specific APIs, like https://updates.drupal.org/release-history/token/all instead of https://updates.drupal.org/release-history/token/8.x
Comment #7
gábor hojtsyYeah but at least project browsing uses core compatibility to list projects (based on core compatibility of their releases) :)
Comment #8
gábor hojtsy@drumm: if this is limited to project browsing then, let's retitle :)
Comment #9
drummThat might make this a duplicate of #3078111: Project browsing/search compatibility filter should work off dependency data, we can use this issue to find other uses.
Such as the “API version” filter on all releases pages like https://www.drupal.org/project/drupal/releases. The easiest thing to do there would of course be removing it. The next best is basic Views filter configuration.
Comment #10
drummComment #11
xjmComment #12
drummCollecting some UI changes in the issue summary. Notable addition is
Comment #13
dwwThat's too bad. :( I think nearly everyone uses those most of the time. The issue queues are going to utterly suck if we no longer can group issues by those things (or something like them). I'm not really sure the right way forward on that.
Comment #14
gábor hojtsy@dww: well, once a module is compatible with 8.x and 9.x it would need both of those applied. Also once a project is 8.6+ compatible but also 9.x, then it is even more complicated :) we may need additional metadata on issues, eg. "confirmed with core version X" where X is multiselect?
Comment #15
tedbowComment #16
tedbowComment #17
tedbowComment #18
tedbowComment #19
drummThe big data model change implementing #66484: Allow issues to be filed against multiple versions/branches. still scares me a bit.
I think the general answer is to use the project’s branches. Core gets 6.x/7.x/8.0.x/8.8.x/9.0.x/etc. ctools gets 6.x-1.x/7.x-1.x/8.x-3.x.
Comment #20
drumm#3085041: Drupal core 9.x.x releases should not attach API compatibility term is solving the issues that surface directly as a result of core not having an API compatibility internally, which overlaps with some of the issues here.
Comment #21
dwwRight, #19 seems like the right approach. Once contrib is fully semver'ed, projects will care about "all "1.3.x" issues, etc. Whether they're compatible with your version of core will become your own nightmare / composer's problem. But once you or your robots figure out you want token module 1.3.5 installed on your site, and you have a problem, you're going to be in the token issue queue looking for 1.3.x issues, etc. In theory, you no longer care what version of core you're dealing with.
Instead of filing issues against multiple branches (which, indeed, will be something of a nightmare), we might want to consider some issue template guidelines or potentially a paragraph (or whatever related entity of fields you want -- field_collection, etc) you can attach to issues with "reproduced on X environment" with fields like:
- Exact version of this module (or commit hash if you're using dev)
- Version of core
- Version of PHP
- Type / version of DB
- Browser(s) where you see the problem
...
There's no way we want to directly call all of that crap issue metadata, attached to the main issue nodes. But it could be really useful to have an easy way for issue contributors to say "here's structured data about the environment where I experience this issue".
Comment #22
catchIt would be really good to update the issue summary so it's clear what if anything is still 9.0.0-blocking here.
Comment #23
catchIf you filter the modules list by 9.x core-compatibility, only five projects show up, and one is 'bad judgement':
https://www.drupal.org/project/project_module?f%5B0%5D=&f%5B1%5D=&f%5B2%...
Comment #24
gábor hojtsyRe issue summary, the Drupal core side of issues are 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 and a lot of them need triage still.
Comment #25
gábor hojtsyComment #26
gábor hojtsyComment #27
drummThe remaining child issue, #3078111: Project browsing/search compatibility filter should work off dependency data, is now done.
Comment #28
dwwIsn't #3089291: Group issue version “series” by branch instead of API compatibility still in-scope and important for this?
Comment #29
dwwIn Slack, @drumm pointed out that the parent for #3089291: Group issue version “series” by branch instead of API compatibility is actually #2681459: Support contrib semver releases and it's more directly related to SemVer than multiple-core (which are overlapping but distinct efforts). So yeah, fixed it is.
Thanks/sorry,
-Derek