CKEditor builds versioning is confusing

[wwalc]

In the documentation we tell users to follow this link to see all available builds: https://www.npmjs.com/search?q=keywords:ckeditor5-build&page=1&ranking=optimal

The current result is:

although we just announced that the version 0.11.0 has been just published.

This is terribly confusing. I know that internally we understand what's the reasoning behind this. I think however, that it does not make sense to use something that cannot be easily understood by outsiders.

I remember a similar case with Java integration for CKEditor that we had long time ago. Although it was compatible with CKEditor 3.x, to some extent with CKEditor 4.x and so on, people were not able to understand it and thought that it's only compatible with CKEditor 3.5.x as it had such version number. Similarly here, if the version of a build published in npm does not reflect the CKEditor version number, then I think almost everyone will be confused.

I know all ckeditor5 packages have their own release cycle and their own sem versioning, the problem is that these particular packages are "special", IMO.

[Reinmar]

There are two options:

1. We use the same versions for them as for the whole project. This seems to be clear, but it might cause issues:

   • If we'll have a micro release which only fixes some bug in plugin X, the whole project's version will be bumped, but then why bumping builds which weren't affected? Will we publish an empty release?
   • New builds will have to start from the main project's version, not from 1.0.0.

2. We add project version to each builds' description. Instead of "CKEditor 5 classic editor build." we may write "CKEditor 5 (v3.1.7) classic editor build.". This description is well visible on npm and might calm down confused developers.

[wwalc]

If we'll have a micro release which only fixes some bug in plugin X, the whole project's version will be bumped, but then why bumping builds which weren't affected? Will we publish an empty release?

Suppose that there was an issue that only affected a plugin from balloon editor. If we go ahead with "2" option, then we'd end up with something like:

@ckeditor/ckeditor5-build-classic
CKEditor 5 (v1.0.0) classic editor build.
0.3.0
@ckeditor/ckeditor5-build-balloon-toolbar
CKEditor 5 (v1.0.1) editor with a balloon toolbar build.
0.1.0
@ckeditor/ckeditor5-build-inline
CKEditor 5 (v1.0.0) inline editor build.
0.1.0

One may wonder "how long do I have to wait for other builds to catch up with 1.0.1".

Not sure if it's better than having just "empty" releases (sporadically ?):

@ckeditor/ckeditor5-build-classic
CKEditor 5 classic editor build.
1.0.1
@ckeditor/ckeditor5-build-balloon-toolbar
CKEditor 5 editor with a balloon toolbar build.
1.0.1
@ckeditor/ckeditor5-build-inline
CKEditor 5 inline editor build.
1.0.1

[Reinmar]

I'm actually ok with this. With no new release of a build in such a case. Or even with an empty release. Or with any other option. Fortunately, we predicted most of these issues and our release tools support them, AFAIR.

This is something I live and think on for such a long time (most of those issues were already discussed... couple of times :D) that I simply know the cons and pros but it's harder for me to assess which is less bad.

[fredck]

After a F2F with @wwalc, we understood that the cases for bumps in individual builds are pretty rare. Most often we'll have changes touching all builds and therefore having them under the same version should be ok. It's very unlikely that we'll have empty releases and if they happen they'll not hurt anyone.

Therefore, amending the previous thoughts about this topic, we should have build versions matching the project version (or marketing version), which is the one set in the ckeditor5 repo.

[Reinmar]

#426 (comment) – I updated my post describing the versioning method.