Calculate the next version

[Nutaboy]

Would be nice if i could calculate the next version based on semantic git if i typ in the command
git-cliff nextVersion -> 1.0.0
I think this would be cool addition

[CHE1RON]

That would indeed be a very nice addition!

[alerque]

If the current version is 1.2.3 how would git cliff know if the next version was going to be 2.0.0 or 1.3.0 or 1.2.4? There are specialty tools for some language ecosystems to analyze code changes and try to make a suggestion or suggestion about what the next version bump should be, but at best these are educated guesses and rely on quite a bit of specialty heuristics. I can't see how git cliff would be expected to incorporate that kind of logic for generic projects in any language.

[CHE1RON]

Conventional commits give us this information, do they not? Projects like git-changelog are doing it based on commits as well:

  -b, --bump-latest     Guess the new latest version by bumping the previous
                        one based on the set of unreleased commits. For
                        example, if a commit contains breaking changes, bump
                        the major number (or the minor number for 0.x
                        versions). Else if there are new features, bump the
                        minor number. Else just bump the patch number.
                        Default: False.

[alerque]

Yes, I suppose if you want to version based completely on conventional commits with fix:==PATCH, feat:==MINOR, and scope!:==MAJOR then I suppose it would be in scope for git cliff to calculate the next expected version.

[orhun]

That makes sense, but the question is how that should be handled? Similar to the --bump-latest argument above so it should use the latest calculated version in the changelog instead of [unreleased] section? Any other ideas?

[CHE1RON]

Right, instead of unreleased, the calculated next version would be printed!

// Update:
As for the original proposal of having a command for printing the next version (based on commits), you might also do something along the lines of sed -n '2p' CHANGELOG.md | cut -d'"' -f 2 to get the current version from the generated changelog file 🤔

[orhun]

I implemented this in #309 using @MarcoIeni's awesome next_version crate 🎉

Review/testing is welcome!

[CHE1RON]

I tested it and loved it!

[juandagilc]

Hello,
This does not work for me on Windows. I installed using cargo install git-cliff.

git cliff --bump 
error: unexpected argument '--bump' found

  tip: to pass '--bump' as a value, use '-- --bump'

Usage: git-cliff [FLAGS] [OPTIONS] [--] [RANGE]

The help file does not suggest --bump as an option:

$ git cliff -h
git-cliff 1.3.1
git-cliff contributors <git-cliff@protonmail.com>
A highly customizable changelog generator ⛰️

Usage:
  git-cliff [FLAGS] [OPTIONS] [--] [RANGE]

FLAGS:
  -h, --help        Prints help information
  -V, --version     Prints version information
  -v, --verbose...  Increases the logging verbosity
  -i, --init        Writes the default configuration file to cliff.toml
  -l, --latest      Processes the commits starting from the latest tag
      --current     Processes the commits that belong to the current tag
  -u, --unreleased  Processes the commits that do not belong to a tag
      --topo-order  Sorts the tags topologically
      --context     Prints changelog context as JSON

...

Can you please suggest if I am doing something wrong, or if you need more info to debug?
Thanks!

[juandagilc]

It works if built from source:

$ ./target/release/git-cliff.exe -h
git-cliff 1.3.1
git-cliff contributors <git-cliff@protonmail.com>
A highly customizable changelog generator ⛰️

Usage:
  git-cliff [FLAGS] [OPTIONS] [--] [RANGE]

FLAGS:
  -h, --help        Prints help information
  -V, --version     Prints version information
  -v, --verbose...  Increases the logging verbosity
      --bump        Bumps the version for unreleased changes
  -i, --init        Writes the default configuration file to cliff.toml
  -l, --latest      Processes the commits starting from the latest tag
      --current     Processes the commits that belong to the current tag
  -u, --unreleased  Processes the commits that do not belong to a tag
      --topo-order  Sorts the tags topologically
      --context     Prints changelog context as JSON

...

[orhun]

Yeah this feature is not released yet.

It works if built from source:

Great!

You could also install the git version for testing:

cargo install --git https://github.com/orhun/git-cliff

[dylan-bourque]

First of all, love the tool! Unfortunately, I'm seeing what looks like a bug in this functionality.

I have 2 unreleased commits, one chore and one feat, both with associated scopes. When I run git cliff -bump .... against my repo it's generating a patch version bump, not a minor version.

The exact command I'm running is git cliff --unreleased --bump --prepend CHANGELOG.md. I can share my cliff.toml , my commit log, and the full output with -vv if it helps.

[alerque]

Typically when reporting a bug it is better to open a new issue (if no existing one covers the specific bug) not comment on a closed feature request. That way it's easier to determine if the report is actually a bug, and then track when and how it gets fixed.

[dylan-bourque]

I can certainly do that.

[dylan-bourque]

Looks like this was called out in other issues already and the author of the next_version crate is saying the behavior is correct because the repo is currently at v0.x (link). 😞

[orhun]

We can probably have an option to change the behavior since this is reported more frequently than I was expecting 🐻

[dylan-bourque]

For context, I'm looking to use this for a Go project and, unfortunate, staying at v0.x indefinitely is pretty common. Always generating a patch version for v0.x won't work for me.