conventional-changelog VS changie

conventional-changelog-conventionalcommits is a package used for creating conventional commits and has a bit more configuration possibilities with changelogs in contrast to the default Angular commit scheme.

Finally, it is also interesting to be able to automatically generate the CHANGELOG file from the commit messages. There are various tools for this, one of them is Conventional Changelog

Some projects generate change logs automatically from commits. For example, angular uses conventional-changelog.

I'm under the understanding from this issue that in semver, a package that is <1.0.0 is considered unstable. This means that a breaking change can occur at any version, usually between minors.

conventional-changelog-conventionalcommits

[1] - https://github.com/conventional-changelog/conventional-chang...

I dont use myself, but some people follows something like the conventional commit spec, and then uses a generator.

@semantic-release/commit-analyzer It determines the type of our release (e.g. major, minor, patch) by analyzing commits with conventional-changelog. semantic-release uses Angular Commit Message Conventions by default.

That is all for now. Reach me on twitter @miniScruffDev or by starting a discussion on GitHub.

Yes, there is changie - a golang tool that inspired me actually.

The complete source for this generation is here in gen.go and might help anyone else who wants to implement there own docs from code.

A short example is the one from Changie itself that asks for an issue number and adds a link when formatting. Changie's .changie.yaml is basically the default configuration with the issue choice added.

That is all for now. Reach me on twitter @miniScruffDev or by starting a discussion on GitHub.

I tend to create a package or file for handling configs with a load or init method depending on how it is loaded ( yaml or env vars ). Here is a bigger example for my own CLI tool Changie https://github.com/miniscruff/changie/blob/main/core/config.go.