32 releases
new 0.2.20 | Nov 21, 2024 |
---|---|
0.2.18 | Jun 18, 2024 |
0.2.15 | Mar 8, 2024 |
0.2.12 | Dec 30, 2023 |
0.1.1 | Mar 27, 2022 |
#431 in Parser implementations
8,555 downloads per month
Used in 12 crates
(2 directly)
27KB
306 lines
next_version
Library to calculate next semantic version based on conventional commits.
It does not analyze git history, the list of commits must be provided by the user.
Credits
Parts of the codebase are inspired by cocogitto.
lib.rs
:
Library to calculate next semantic version based on conventional commits.
It does not analyze git history, the list of commits must be provided by the user.
Version changes
Non conventional commits
If conventional commits are not used, the patch is incremented.
use semver::Version;
use next_version::NextVersion;
let commits = ["my change"];
assert_eq!(Version::new(1, 2, 3).next(commits), Version::new(1, 2, 4));
0.0.x
versions
In 0.0.x
versions the patch is always incremented:
use semver::Version;
use next_version::NextVersion;
let commits = ["my change"];
assert_eq!(Version::new(0, 0, 4).next(&commits), Version::new(0, 0, 5));
let commits = ["feat!: break user"];
assert_eq!(Version::new(0, 0, 1).next(&commits), Version::new(0, 0, 2));
0.0.x
to 0.1.x
should be intentional (not automated) because the author communicates an higher level of
API stability to the user.Features
If a feature comment is present:
- If the major number is
0
: the patch is incremented. - Otherwise: the minor is incremented.
use semver::Version;
use next_version::NextVersion;
let commits = ["my change", "feat: make coffe"];
assert_eq!(Version::new(1, 2, 4).next(&commits), Version::new(1, 3, 0));
assert_eq!(Version::new(0, 2, 4).next(&commits), Version::new(0, 2, 5));
0
,
we don't increase the minor version because the bump from 0.x.y
to 0.(x+1).0
indicates a breaking change.Breaking changes
Breaking changes will increment:
- major if major is not
0
. - minor if major is
0
.
use semver::Version;
use next_version::NextVersion;
let commits = ["feat!: break user"];
assert_eq!(Version::new(1, 2, 4).next(&commits), Version::new(2, 0, 0));
assert_eq!(Version::new(0, 4, 4).next(&commits), Version::new(0, 5, 0));
According to the conventional commits specification, breaking changes can also be specified in the footer:
use semver::Version;
use next_version::NextVersion;
let breaking_commit = r#"feat: make coffe
my change
BREAKING CHANGE: user will be broken
"#;
let commits = [breaking_commit];
assert_eq!(Version::new(1, 2, 4).next(&commits), Version::new(2, 0, 0));
Pre-release
Pre-release versions are incremented in the same way, independently by the type of commits:
use semver::Version;
use next_version::NextVersion;
let commits = ["feat!: break user"];
let version = Version::parse("1.0.0-alpha.1.2").unwrap();
let expected = Version::parse("1.0.0-alpha.1.3").unwrap();
assert_eq!(version.next(commits.clone()), expected);
// If the pre-release doesn't contain a version, `.1` is appended.
let version = Version::parse("1.0.0-beta").unwrap();
let expected = Version::parse("1.0.0-beta.1").unwrap();
assert_eq!(version.next(commits), expected);
Build metadata
Build metadata isn't modified.
use semver::Version;
use next_version::NextVersion;
let commits = ["my change"];
let version = Version::parse("1.0.0-beta.1+1.1.0").unwrap();
let expected = Version::parse("1.0.0-beta.2+1.1.0").unwrap();
assert_eq!(version.next(commits.clone()), expected);
let version = Version::parse("1.0.0+abcd").unwrap();
let expected = Version::parse("1.0.1+abcd").unwrap();
assert_eq!(version.next(commits.clone()), expected);
Custom version increment
If you don't like the default increment rules of the crate,
you can customize them by using VersionUpdater
.
Dependencies
~4–6MB
~111K SLoC