Does it need to be a cargo subcommand?

[thomaseizinger]

As noted in #202, I've been thinking about building a similar tool. I was wondering why you went the route of a cargo subcommand? In my design sketches, I considered it to be language agnostic.

Did you have some integration in mind that would make this only apply to Rust projects?

[matthiasbeyer]

Hi! Thanks for filing this!

I have no really strong reason for making it a cargo subcommand, but I still have some ideas in the back of my head, which are cargo-related.

For example, something I can think of are automatic checking of whether the changelog contains a certain section before a release, checking whether cargo-semver-checks (if there's an API for that tool) reports things that are noted in the changelog entries, maybe some integration with other cargo related tools to do some sanity checking before generating the changelog...

Just to mention it:
There is also the changie tool, which is way ahead of what cargo-changelog can currently do! Maybe that fits your needs better than cargo-changelog, or solves the problems you want to solve with your own tool.

You are also very much welcome to contribute to this project if you like! I am not really fast in terms of progress here and would love to see someone helping! 😄

[thomaseizinger]

For example, something I can think of are automatic checking of whether the changelog contains a certain section before a release, checking whether cargo-semver-checks (if there's an API for that tool) reports things that are noted in the changelog entries, maybe some integration with other cargo related tools to do some sanity checking before generating the changelog...

Funny you mention it, we've already integrated cargo semver-checks into our workspace CI. At the moment, we run one CI job per crate (i.e 33 in total). My (current) vision with something like #202 is to have the following workflow:

• Run CI with tests etc
• Check for a (structured) changelog entry
• Derive the version bump from this one entry
• Invoke cargo semver-checks with either patch/minor/major with current master (not crates.io release) as baseline and the PR as current
• If it fails, then the user did not put the correct semver bump into the changelog entry and we fail CI

At release time, we can then trust that each PR has been checked individually and we would do a last sanity check that the combination of all changes also results in the bump as described by the accumulation of all changelog entries.

I am hoping that this process:

• Gives us good visibility into what PR is a breaking change in isolation
• Scales well with the number of crates in a workspace
• Plays well with squash-merging (which is the main reason we can't use conventional commits; one commit may touch multiple crates)
• Avoids merge conflicts in changelogs and manifest files
• Allows for completely automated releases

Just to mention it:
There is also the changie tool, which is way ahead of what cargo-changelog can currently do! Maybe that fits your needs better than cargo-changelog, or solves the problems you want to solve with your own tool.

Thanks, I'll take a look at it :)

I would prefer if the workflow would just be baked into an (opinionated) tool instead of requiring a lot of configuration.

[thomaseizinger]

Following up on this, my more concrete vision is:

• Name: semverlog (subject to bike-shedding ofc)
• Commands:
  • compile-changelog: Does not change files on disk, prints changelog from all files added since last tag until HEAD (i.e. Git is a requirement)
  • compute-bump-level: As discussed, breaking changes are major, minor if < 1.0. I do envision some language integration here, i.e. be able to read versions from Cargo.toml, package.json, etc
• Files are stored in .changelogs
• Changelog entries can have a "priority" and will be sorted by that: Should be human-centric, not just by a timeline
• Files should be able to have any name: I'd like contributers to be able to use this without having to install a tool by just copy-pasting a template file.

In the end, what I envision releases to be is:

cargo release $(semverlog compute-bump-level)
echo -e "$(semverlog compile-changelog)\n$(cat CHANGELOG.md)" > CHANGELOG.md

[TheNeikos]

Some alternative name ideas:

• changeling
• versioneer
• logsmith
• chglog
• releasegen
• changelogger