Save plugins versions during release

[Reinmar]

I've realised that it'll be very hard (if not impossible) to switch the whole project to a state in which it was at release X. Each package is versioned differently, so it's not like "switch all packages to 3.5.2".

So, during the release we should in some way write down all the package versions (preferably in package.json).

What we could do is always specifying tag after the repo address, like:

  "dependencies": {
    "ckeditor5-basic-styles": "ckeditor/ckeditor5-basic-styles#v0.1.0",
    "ckeditor5-delete": "ckeditor/ckeditor5-delete#v0.1.3",
    "ckeditor5-editor-classic": "ckeditor/ckeditor5-editor-classic#v0.1.0",
    "ckeditor5-engine": "ckeditor/ckeditor5-engine#0.5.0",
    ...
  },

Then, when bumping up version of ckeditor5 we'll also bump specific versions for packages that were also released this time.

When you install ckeditor5 directly through npm install ckeditor5 you will get exactly the same set of dependencies as was used when it was released. However, our dev tools will ignore the specified versions (and simply get you latest master) when cloning and checking out package repositories, unless you use the option to check out exactly to specified branches. We'll need that for getting back to a certain point in the history or to use a configuration of branches (which we do while developing bigger things).

One more thing that we can do is switching dependencies from GitHub URLs to real package names once those will be published. The dev tools will have no problems in getting GH URLs for npm packages.

BTW. the final result will look like this (see ckeditor/ckeditor5-design#145):

  "dependencies": {
    "@ckeditor/ckeditor5-basic-styles": "^0.1.0",
    "@ckeditor/ckeditor5-delete": "^0.1.3",
    "@ckeditor/ckeditor5-editor-classic": "^0.1.0",
    "@ckeditor/ckeditor5-engine": "^0.5.0",
    ...
  },

But the dev tools will still have to support the current syntax (if you want to use a package that weren't yet published).

WDYT?

[fredck]

Sounds like a good plan, but we should certainly go with the use of real package names to bring the benefit of the automatic upgrade on minor versions (caret ranges).

[scofalik]

NPM package names +1

[oleq]

Do you think we could automate the process of updating ckeditor5/package.json? Like gulp [command] which would crawl all the dependencies, fetch their version numbers and fill the main package.json? It would speed up the release process because with dozens of dependencies it would be hard to keep track of each pkg and type the version manually.

[maxbarnas]

@oleq: this shouldn't be a problem. Actually I think this is one of the things that @Reinmar implicitly wants to be done.

[Reinmar]

Sounds like a good plan, but we should certainly go with the use of real package names to bring the benefit of the automatic upgrade on minor versions (caret ranges).

You mean that it's better to have:

"@ckeditor/ckeditor5-basic-styles": "^0.1.0",

Instead of:

"@ckeditor/ckeditor5-basic-styles": "ckeditor/ckeditor5-basic-styles#v0.1.0",

because dependencies of a specific ckeditor5 versions will always contain most up to date versions of its dependencies?

This is actually a good point. But it has a downside as well, which is that installing ckeditor5 in a specific version won't necessarily mean exactly the same version that we tagged during release.

That's totally understandable of course, and even desirable if semver was used correctly. But we need to remember that our dev tools will need to be more specific when the "move to specific version" option was used.

[Reinmar]

Do you think we could automate the process of updating ckeditor5/package.json? Like gulp [command] which would crawl all the dependencies, fetch their version numbers and fill the main package.json? It would speed up the release process because with dozens of dependencies it would be hard to keep track of each pkg and type the version manually.

Yep, we'll definitely need to include this in our release tools. I've begun gathering some ideas about them in ckeditor/ckeditor5-design#145.

[fredck]

You mean that it's better to have:

"@ckeditor/ckeditor5-basic-styles": "^0.1.0",

Yes.

[pjasiun]

Another use-case is that another project wants to fix CKE version it uses. There should be a command to save not only tagged versions but also all hashes of all packages in the package.json if the dependent project use specific version (for instance because of some fixes)

[Reinmar]

OK, we finally closed #378. However, we haven't managed to introduce the release tasks for the main package (ckeditor5) because there are some minor differences between them (see https://github.com/ckeditor/ckeditor5-dev/issues/85). For the time being, we'll be releasing the main package manually.

[Reinmar]

I think that we can close this ticket. Most of the things are automated already and, most importantly, we agreed on how those things should work.

There's also #426 (comment) which summarises our approach to versioning.