Release tools for packages

[Reinmar]

Requirements

For all packages:

• Generate changelog based on commits in master. This shouldn't include commits in ticket branches (so only merge commits count). Changelog entries for PRs will be generated out of merge commits and other commits in master.
• We should be warned about commits in master which don't match the pattern and the commits should be ignored. This can be done when generating the changelog and should not block generating it.
• The new piece of changelog should be injected at the beginning of CHANGES.md. We cannot override the whole CHANGES.md because it might have been fixed manually (some typos corrected just before previous releases).
• While making a PR, one should propose a merge message, based on the format that we use. We'll use PR and issues templates on GitHub to speed this up.
• It should be possible to generate and commit the changelog before tagging. Preferably, by a separate command.
• Based on the commits, the tool should also be able to propose whether the new release will be a patch, minor or major (to conform to semantic versioning).
• Finally, once everything is reviewed, the tool should be able to update package.json, tag the release, create release on GH, publish the package on npm.

For the main package:

• We'll need to have a combined changelog somewhere. What changed in a release of the whole ckeditor5 (where we're going to change package versions in the package.json and other stuff). We don't have to automate this so badly. At the beginning, this can be done manually (except bumping up versions! :D). Also, it's unclear yet whether in the main changelog we should have just links to the other package releases or their whole changelogs duplicated.
• And mooar...

[Reinmar]

Changelog entries for PRs will be generated out of merge commits and other commits in master.

I have a second thought about this that such a behaviour could be limiting if a ticket branch does couple of things at the same time. Is it something that we want to consider? Or should there be a rule that a single PR has a single changelog entry?

[fredck]

Or should there be a rule that a single PR has a single changelog entry?

+1. Changelogs should be compact. One is only interested in high-level details here.

[Reinmar]

And I guess we all agree that we don't want to squash commits before merging ticket branches to master? Squashing is what Angular does so they can, later on, generate changelog out of all commits. But I really don't like such approach. For me, there was always a great value in the details how a certain bug was fixed e.g.

[Reinmar]

We're trying to design commit message standard. To do that we need to understand what kind of changes we make and how to mark those which should end up in the changelog.

So far I see:

• Included in the changelog: Fix, Feature, Enhancement (?)
• Not included in the changelog: Internal Fix, Internal Feature, Internal Enhancement, Docs, Tests

Plus, there will be a special notation to mark breaking changes.

Do we miss anything?

Do we have a shorter word for enhancement?

[fredck]

Do we have a shorter word for enrichment?

No, "improvement" has 11 letters, as well :D

[Reinmar]

I forgot about the most important one – "Code Style"