Release commit messages display basic information: chore(release): %s
Some time ago I used conventional-github-releaser which would automatically add the changes (of CHANGELOG.md) to the release notes, like this: conventional-github-releaser/releases
I think this is a neat way to handle release notes.
Ping @stevemao you have wrote most of conventional-changelog/conventional-github-releaser right? Can you possibly explain shortly what sort of work this would entail?
So i actually took a look at the tool, and I would say the best way to do this right now is calling them one after another, e.g. in your package.json scripts:
...
"scripts": {
...
"release": "standard-version",
"postrelease": "git push --follow-tags && conventional-github-releaser",
...
}
...
The tools both read the changelog independently right now, and eventually it would be cool if the github releaser could just read the CHANGELOG.md written by standard-version, but I'm hesitant about completely integrating it as a dependency. That would bring in a lot of new complexity. Since it is trivial to set them up to run one after another, it's IMO better to just make that as painless as possible.
@Tapppi @SteveVanOpstal I think one of the neat things about standard-version is that it's (relatively) agnostic of a specific platform; e.g., it should be able to handle both BitBucket and GitHub.
I'd prefer to see a well documented, best practices, workflow between conventional-github-releaser and standard-version, rather than adding this functionality into the module.
The solution provided by @Tapppi makes a lot of sense. And indeed @bcoe, it seems like documentation on this would be a nice addition. Other people might run into this too.
Most helpful comment
So i actually took a look at the tool, and I would say the best way to do this right now is calling them one after another, e.g. in your
package.jsonscripts:The tools both read the changelog independently right now, and eventually it would be cool if the github releaser could just read the
CHANGELOG.mdwritten bystandard-version, but I'm hesitant about completely integrating it as a dependency. That would bring in a lot of new complexity. Since it is trivial to set them up to run one after another, it's IMO better to just make that as painless as possible.