CKEditor 5 backwards-compatibility policy needed

This is about core policy, changing project.

The policy for dependencies is Core dependency release cycles → . It is a general guideline for evaluation dependency updates. For the most part, minor versions of Drupal core include the latest minor and patch release of a dependency.

But CKEditor does not backport bug fixes and major releases often occur in less that 6 months. To get bug fixes Drupal may update to a new major of CKEditor in a new minor release. That happened for 10.3.0-beta1, specifically in 📌 Update CKEditor 5 to 41.2.0 Fixed , which caused the disruption mentioned in the issue. When there are breaking changes they should be in the release notes but I see there were not for 10.3.0-beta1. That was most likely because that issue was not tagged correctly. And that was a human error and not a problem with a policy.

Therefore, I think this issue can be closed because the policy is working as designed.

I can agree with that. May even be a neat gitlab project to see if we can opt into different versions of ckeditor5. Not a core problem but idea came to mind reading this.

The only other option with ckeditor5 would be to move the module to contrib, so that it can release new versions when new ckeditor5 releases come out, and potentially be a bit closer to semver (new major for ckeditor5 majors, new minors for minors, new patch releases for patch releases). However that would be a huge change that would require its own issue and discussion.

This can't be RTBC as it stands, because we can't provide BC policy for CKEditor. Only CKEditor can do that. It's an external dependency.

And we can't stop updating CKEditor, because we must keep it up to date, because they offer frequent security updates and we have to be on the latest versions or instead of getting those BC breaks with minors, you'd be getting them in security windows instead.

@timurtripp I feel your pain, but changing CKEditor's BC policy is something that's outside of core's ability to address, unfortunately. Believe me, we've reached out many times with our concerns with how disruptive their version and backwards-compatibility practices are for our ecosystem.

Setting back to active to discuss what we can do (if anthing). #6 will be discussed in a separate issue that we're considering at the moment, so let's leave that aside for now.

I think any policy change should be in Core dependency release cycles → . That document already explains how dependencies are updated in patch/minor/major versions whereas the BC policies refer to Drupal code.

Something like a new item my be sufficient.

Every minor release CKEditor is updated to the latest version, which maybe a major version, and may include BC breaks. This is necessary to keep up to date with frequent security updates. CKEditor does not use Semver and does not have a regular release schedule.

@quietone I do think a specific mention for CKEditor is correct, but I think we should also add the caveat that dependencies in general might break BC on us and we just make our best effort to mitigate disruptions. It happens all the time with e.g. jQuery and to some extent with Symfony. It also happened this release with the PostCSS/Stylelint issue.

I think we probably want to at least reference it on the allowed changes policy as well, maybe like so:

Before

Third-party code

• patch- and minor-level library updates
• new library dependencies
• deprecations of a previous dependency once its code is no longer used

After

Third-party code

• patch- and minor-level library updates ( dependency update policy → )
• new library dependencies
• deprecations of a previous dependency once its code is no longer used

Aside: There is a trailing -0 on the URL alias for https://www.drupal.org/about/core/policies/core-dependency-policies-and-... → -- we should look into that.

Belatedly adding the tag; this will need our collective signoff prior to being marked fixed.

@quietone Also note that the frontend dependency child page → already says this about CKEditor:

The CKEditor maintainers expect this to slow down as the product matures, and are looking into ways to refine their BC policy to reduce breaking changes in public APIs.

...But it was clearly not enough to stop this issue from being filed. :)

That makes sense. I updated the IS with a proposal which has 3 changes in 2 files.

It helps my searching to have policy in the title

Aside: There is a trailing -0 on the URL alias is resolved