because I wanted to add some editor convenience features to CKEditor (namely Auto Formatting), I spent some time over the weekend to see how much effort it is to upgrade CKEditor5 to a more up-to-date version. We are currently running CKEditor5 16.0 released in 2019 (!). Today, version 43.3 is up-to-date.
Turns out it was rather easy (see this PR); and I have a running backend with editing again already. Still needs some finetuning; but that’s easily doable.
Question is only when to include this PR, as it needs (minor) adjustments to all CKEditor plugins I guess.
So, into which release shall we include this change?
On the Dresden sprint in May we already considered this also a goal for Neos 9
And in this issue i collected some technical thoughts as well:
But to answer your question: Technically it would be breaking to all? the known pubic CKeditor plugins as well as those hidden in custom projects
If it turns out that simultaneously supporting two versions (by checking if a method exists) is easy, might be an argument to still do it in a minor. I dont know how big of a burden it would be otherwise as package maintainer would have to manage possibly a Neos 8.3 8.4 and 9.0 version
On the conference we said Neos 8.4 would be “easy” to upgrade to, so its now in the hands of the community to decide what that means
A minor version should generally contain no breaking changes, but i also found a little disclaimer that has been probably on the roadmap since ember js but it states:
Note: For JavaScript we have no fully defined public API yet, except the documented editors/validators.
So by that we can do ANYTHING
Joking aside im not fully sure yet but i tend to say 8.4
I expect 9.0 to be released before 8.4 – can we include it in both?
Hi there! I was really surprised that during the sprint, upgrading CKEditor didn’t cause as many headaches as it did in the past. However, in the end, we’re likely to break some CKEditor plugins. The issue is that we’re not entirely sure what will break yet, since the list of API changes is long, and we don’t know what others are currently using.
During the sprint, we tested some plugins, and not every plugin stopped working. But once we move to version 8.4, we’ll likely end up breaking our SEMVER promise for extensibility.
So I am unsure. I would love to see it in 8.4, but also don’t want to have angry users because they need to adjust the whole package to be 8.4 compatible.
because the votes are about evenly split; and some ppl tend to do include it in 9.0 only, I would follow and only include it in 9.0; and not in 8.4. Just to be on the safe side
I just want to repeat what I wrote in a different place because I think it’s an important point: IMO the most important feature of a Neos 8.4 release is a greater forward-compatibility to Neos 9.0.
Switching from 8.x to 9.0 will be a big step anyways, but if we could make that a little smaller by already preparing developers/integrators to the new world in some parts that’s a win IMO.
I’m not sure how much pain the CKEditor update would mean, but if it’s manageable (or even configurable) I would strongly vote for “distributing the breaking changes”
However we decide it has to be fast because otherwise it will land in Neos 10 Id say push the Neos 9.0 pr forward and even merge it, later we still can backport it to 8.4.
