calculate the next version

[Mcdostone]

Hey,

I would like to automatically calculate the next version based on cargo-semver-checks's analysis. So far, the output is somthing like this

cargo semver-checks --baseline-version 0.0.1
    Checking todo_command v0.0.1 -> v0.0.1 (no change)
     Checked [   0.010s] 89 checks: 88 pass, 1 fail, 0 warn, 0 skip

--- failure struct_missing: pub struct removed or renamed ---

Description:
A publicly-visible struct cannot be imported by its prior path. A `pub use` may have been removed, or the struct itself may have been renamed or removed entirely.
        ref: https://doc.rust-lang.org/cargo/reference/semver.html#item-remove
       impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.35.0/src/lints/struct_missing.ron

Failed in:
  struct todo_command::ImportFunctionCommand, previously in filesrc/import_function.rs:16

     Summary semver requires new major version: 1 major and 0 minor checks failed
    Finished [   9.928s] todo_command

For a human, the next version is obvious. For a machine, it's not that easy. I can do grep but it's not very convenient.
Is there a way to print only the next version?

cargo semver-checks --baseline-version 0.0.1 --calculate-next-version
1.0.0

Thank you!

[obi1kenobi]

Hi @Mcdostone! Thanks for the suggestion. Could you say a bit more about the intended use case of such a feature? Where would it be used, and how?

So far, we've considered it a few times for a few different use cases, but we always felt it was too risky given that there are still many breaking changes that cargo-semver-checks will not catch today (see #5). We don't want to give users a false sense of confidence when we can't actually guarantee the correctness of our version number recommendation.

The other open question is what to do about warning-level lints (the lint shown in your example output is an error-level lint, but some lints will only warn). Should the version bump recommendation of warning-level lints be heeded in this hypothetical feature, or not?

I'd love to understand your use case better, and see if there's perhaps a different way to approach solving the problem!

[Mcdostone]

Hey, sorry for being vague. I'm working on a github action pipeline. One of the workflow consists of preparing a release branch. At this time, this workflow is manually triggered and 1 input is required ( major, minor or patch):

# .github/workflows/prepare-for-release.yml
on:
  workflow_dispatch:
    inputs:
      bump:
        type: choice
        required: true
        description: Run 'cargo semver-checks' to help you decide
        options: 
          - major
          - minor
          - patch

In a few words, the workflow:

1. creates a new branch to prepare the release,
2. runs cargo release <input>,
3. runs cargo semver-checks --release-type <input>,
4. If everything is correct, it creates a pull request with a changelog and your tool's analysis.

I would like to get rid of the manual workflow dispatch and automatically generate the PR without user input.
That's why I would need to compute/calculate the next semver version.

Regarding your second question, merging the PR to main is not automated since it requires people to review it.
People can accept or reject the PR based on the tool's analysis and warning-level lints.

I'm aware that it's risky to 100% trust cargo-semver-checks and it's fine for my use case.

It's my first time using your tool so there may be a better approach.

Thanks for your help

[obi1kenobi]

Just to give you a specific example, cargo-semver-checks today will claim that there is no breaking change in the following code:

// old code
pub fn example(value: String) {}

// new code
pub fn example(value: i64) {}

If I'm correctly understanding how cargo-semver-checks would fit into the proposed workflow, wouldn't this change result in a patch version bump PR?

Are you sure that's completely fine for your workflow?

[Mcdostone]

Regarding your example, I assume that reviewers should debate about this potential breaking change. In my use case,
cargo-semver-checks is just a tool giving information to people.

To give you some context, I'm about to publish a new crate. So far, nobody is using it except me. If I make breaking changes violating semver, that's ok for now since there's nothing at stake at the moment (and perhaps never).

I just wanted to play with cargo-semver-checks and help me choose how to bump versions in a near future.

If you feel this sounds like a bad idea (and you know better than me), it's alright :)
I can still code a little script based on the output.

[obi1kenobi]

I'm worried that the existence of such a flag might lead other folks (who might not be as thoughtful as you!) into making bad versioning decisions. If it's alright with you, I'd prefer if you just script it based on the existing output for now.

Tangentially, I've been designing a workflow around cargo-semver-checks where we can label PRs as semver:minor or semver:major etc. based on the tool output. Then release workflows could check the PRs being released for major/minor labels and update versions accordingly. And since PR labels can be edited by humans as well as by the cargo-semver-checks workflow, we could rely on PR reviewers to set the semver:major label in cases where there's breakage that the tool can't detect yet.

What do you think about that approach? Would that be helpful? Might it address the same use case you're currently targeting? I don't have a concrete timeline for this workflow yet — I'm gathering feedback on it before I start building — but I'm hoping to build it sooner rather than later.

[Mcdostone]

Alright! I wrote dumb bash script. If other people have the same need:

#!/usr/bin/env bash

latest_tag=$(git tag | head -n 1)
if [ -z "$latest_tag" ]; then
    echo "patch"
    exit 0
fi

printf "Most recent version: '%s'\n" $latest_tag >&2
commit=$(git rev-list -n 1 "$latest_tag")
printf "        Commit Hash: '%s'\n" $commit >&2

for bump in patch minor major; do
  cargo semver-checks --baseline-rev "$commit" --release-type "$bump"
  if [ "$?" == "0" ]; then
    echo "$bump"
    exit 0
  fi
done

exit 1

The approach with label PRs is interesting. Are you planning to release this feature with obi1kenobi/cargo-semver-checks-action@v2 ?

[obi1kenobi]

Nice script! And yes, the plan is to augment the obi1kenobi/cargo-semver-checks-action action (perhaps as a v3, or perhaps as a v2.x) so it can be used both for PRs and at publish time. Currently it's best suited for running at publish time, so the PR + labeling workflow would be new functionality.

[obi1kenobi]

Also, thank you for the sponsorship, I appreciate it 🙌