ckeditor / ckeditor5-design

☠ Early discussions about CKEditor 5's architecture. Closed now. Go to https://github.com/ckeditor/ckeditor5 ☠
58 stars 12 forks source link

Releasing #145

Closed Reinmar closed 7 years ago

Reinmar commented 8 years ago

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.

Reinmar commented 8 years ago

First reminder: https://github.com/ckeditor/ckeditor5-design/issues/3#issuecomment-216550057

Reinmar commented 8 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.

fredck commented 8 years ago

I would go for npm scopes. As we have a rich multi-repo architecture, the naming collision chances are much bigger with us.

Reinmar commented 8 years ago

Very important and very related topic: https://github.com/ckeditor/ckeditor5/issues/245.

Reinmar commented 8 years ago

And another thing to keep in mind: https://github.com/ckeditor/ckeditor5/issues/245#issuecomment-233589489

Reinmar commented 8 years ago

@oleq made some quick attempt to automate this a bit: https://github.com/ckeditor/ckeditor5-dev-env/issues/13

Reinmar commented 8 years ago

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 :(.

(https://codetree.com/projects/bTEc/issues?exclude_labels=resolution%3Aduplicate%2Cresolution%3Ainvalid%2Cresolution%3Awontfix&milestone=-&status=closed)

Reinmar commented 8 years ago

Two tools which we could use;

Reinmar commented 8 years ago

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.

Reinmar commented 7 years ago

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