Open aesopwolf opened 7 years ago
Hi dropping in from the @conventional-changelog
team. We have many tools for parsing git commits, doing releases etc. with different formats. I personally am most familiar with the angular convention, but I'm pretty sure you can find useful stuff from us. E.g. Our core changelog generator that is used by both semantic-release
and standard-version
. Just gimme a holla if you want to know more.
@Tapppi what do you guys use to detect breaking features? Or when you need to bump to the next MAJOR version number?
The most basic/naive solutions I can think of:
release
is currently doingI'm just wondering if there isn't a better/more-automated way though.
@aesopwolf The angular convention dictates that breaking change commits should have a footer of BREAKING CHANGE:
and the rest of the commit message is reserved for that change.
See the standard-version changelog for an example. So for example, the 4.0.0 has a bug fix
include merge commits in the changelog
and if you go to the commit linked to that change you'll find the BREAKING CHANGE
that is included as the 4.0.0 breaking change
merge commits are now included in the CHANGELOG.
Docs on it can be found in the conventional-changelog-standard commit guidelines or in the more detailed angular docs linked there.
Indeed, it would be great if we could setup release
to use the conventional-changelog format.
My team uses feature branches, and we also use the "Squash and merge" feature within GitHub. This makes our master branch look like this (by default):
So, do you think it would be possible for
release
to detect commit messages in that format (instead of using parenthesis such asError logging works now (patch)
)? The Angular guidelines could be used:listed under
### Minor Changes
:listed under
### Patches
:So anything that begins with those words would automatically be sorted to
minor
orpatch
.