Detect the appropriate version from compatibility checks

[jrmuizel]

It would be handy to have integration between cargo-release and https://github.com/rust-lang-nursery/rust-semverver

[sunng87]

Nice, we can call semverver to give user a suggestion on release level

[ibabushkin]

I've just noticed (in this issue: rust-lang/rust-semverver#61) that this is a feature people are interested in. How exactly do you expect to interact with rust-semverver? I'm not sure parsing it's text output would be the most comfortable way of approaching this. I'm open for your input.

[sunng87]

I haven't got time to looking into detail with rust-semverver. I really wish it can provides an output format that friendly for other tools to parse.

[dbkaplun]

Here is the entirety of what cargo semver outputs to stdout:

$ cargo semver 2>/dev/null
version bump: 0.1.2 -> (breaking) -> 0.1.3

A bash one-liner, adapted from the README:

$ cargo semver 2>/dev/null | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+' | tail -n1
0.1.3

[ibabushkin]

On 2018-06-17, Dan Kaplun wrote: Here is the entirety of what `cargo semver` outputs to stdout: ```sh $ cargo semver 2>/dev/null version bump: 0.1.2 -> (breaking) -> 0.1.3 ``` A bash one-liner, adapted from the [README](https://github.com/rust-lang-nursery/rust-semverver#ci-setup): ```sh $ cargo semver 2>/dev/null | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+' | tail -n1 0.1.3 ```

I'm aware, as I built that functionality ;) My point is, parsing the text output is probably somewhat ugly -- I'll look into a library interface or something similar, especially since the user might want to keep the output. Or it could be beneficial to just implement the version update in rust-semverver, by requiring cargo-release.

[sunng87]

@ibabushkin rust-semverver would be a too big dependency to cargo-release. I still recommend a programmer friendly output option for rust-semverver. For example cargo semver --compact that output the suggested version directly.

[ibabushkin]

To get back to this -- how about just shelling out to cargo semver --compact -q (which I have implemented -- it outputs only the recommended version number on stdout but keeps diagnostic info on stderr so it can be passed to the user if deemed necessary) and using its output to do a version bump? The only additional feature necessary is checking whether such a cargo subcommand is available, and calling it if it is present, otherwise telling the user that such a tool is available and that it can be installed seperately. I can open a PR for this if necessary.

That way we'd avoid duplicating functionality and keep the tools decoupled.

[epage]

So the main integration talked about in the comments is auto-choosing the level. Another helpful integration would be that if the level is not a breaking level, then run the tool to ensure an accidental breakage isn't happening.

[ibabushkin]

Well, one can argue about the modality of running semverver obviously, but the main point for me now is whether the proposed level of dependency on an external tool is acceptable to the maintainers. I suppose one can make the behaviour switchable between "no semverver", "run semverver to avoid breakage" and "run semverver and use what it suggests"

[anp]

I would be interested in flags that let me tell cargo-release what kind of release I'm expecting to make: a patch bump, a minor bump, or a major bump, and to have cargo-semver warn me if I were violating those assumptions.

[epage]

https://github.com/iomentum/cargo-breaking might be of interest as an easier tool to integrate

[epage]

Automatically detecting the version is a no go because automated checks aren't sufficient.

We could report the information in cargo release changes (though we might want to change that subcommand to be filtered instead of workspace-wide for performance reasons).

We could also do it as a sanity check at the beginning of the release process (cargo release <ver>) and when bumping the version (cargo release version <ver>). We'd need to do it at a point in the process where error recovery is easy. We'd also need to know when to skip this (e.g. a bin or bin/lib where the lib is an implementation detail) and performance still might be a bit of a concern.

[epage]

Been looking into the concept of generating a changelog from fragments. My thoughts are at epage/epage.github.io#23 (comment)

I think this would allow the changelog to control the version bump which would allow a human to get inbetween the automatic version bumping and the release, to adjust as needed.