-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Save plugins versions during release #245
Comments
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). |
NPM package names +1 |
Do you think we could automate the process of updating |
You mean that it's better to have:
Instead of:
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. |
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. |
Yes. |
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 |
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. |
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. |
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:
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 throughnpm 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):
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?
The text was updated successfully, but these errors were encountered: