Closed Reinmar closed 7 years ago
First question in the topic – are we going to use npm scopes? (every package name will be preceded with @ckeditor/
)
I think that we should use scopes, because it's very likely that there will be name collisions with community packages. We've seen that in the past and we had to find some less obvious names for some CKE4's plugins.
I would go for npm scopes. As we have a rich multi-repo architecture, the naming collision chances are much bigger with us.
Very important and very related topic: https://github.com/ckeditor/ckeditor5/issues/245.
And another thing to keep in mind: https://github.com/ckeditor/ckeditor5/issues/245#issuecomment-233589489
@oleq made some quick attempt to automate this a bit: https://github.com/ckeditor/ckeditor5-dev-env/issues/13
Another thing – before every release we should make sure that all tickets are closed with a proper resolution and those fixed were assigned to milestones, because we tend to forget assigning tickets to milestones :(.
Two tools which we could use;
Quoting @Comandeer:
maybe https://github.com/jzaefferer/commitplease#commitplease ? The Angular rules (aka conventional-changelog) has many tools to generate changelog (https://github.com/conventional-changelog/conventional-changelog ), generate commit messages (https://github.com/commitizen/cz-cli ) and it's a de facto standard now (e.g. Greenkeeper generates commits in this convention). Also semantic-release is based on these commits to calculate the new version.
We tried to start with conventional releases, conventional changelog, etc. but they turned out to not be really flexible and we ended up implementing most of the process ourselves. It's implemented by https://github.com/ckeditor/ckeditor5-dev/tree/master/packages/ckeditor5-dev-env and features automatic changelog generation (based on merge commits, not all commits), version bumping, GH and npm releases for all packages. We also made sure to split the process into two steps – changelog generation and final releasing, so we can review and improve the changelogs.
Anyway, it turned out to be a pretty complex tool, just as we expected :D
Well... this will be a long and tough topic – what we need to release, how to do it, where, etc. I'll write details later on. Now, I've just wanted to have a place to gather some reminders and ideas.