Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Help understanding compatible bumps logic #89

Open
aharpervc opened this issue Jul 27, 2022 · 2 comments
Open

Help understanding compatible bumps logic #89

aharpervc opened this issue Jul 27, 2022 · 2 comments

Comments

@aharpervc
Copy link

Hi, I use this library to get releases from GitHub, and I noticed something I want to get clarity about. I have a new release 0.4.0, but it's being reported as "not compatible" with the current version of 0.3.0. I double checked this behavior with the following, but you basically already have this as a test case here.

# fails
assert_eq!(true, bump_is_compatible("0.3.0", "0.4.0").unwrap());

I see that the bump compatibility logic is this:

# current bump_is_compatible
if other.major == 0 && current.major == 0 {
    current.minor == other.minor && other.patch > current.patch
} else if other.major > 0 {
    current.major == other.major
        && ((other.minor > current.minor)
            || (current.minor == other.minor && other.patch > current.patch))
} else {
    false
}

This seems surprising, because it means only patch versions can be incremented in a 0.y.z version and still be treated as compatible. Is this intentional? I'd expect minor versions to be allowed to increment and be compatible even with 0.y.z versions, similar to how it is compatible in 1.y.z versions.

Eg, if the logic was changed to this (and the single 0.2.0 -> 0.3.0 test case changed), this would make sense to me:

# theoretical bump_is_compatible
Ok(current.major == other.major
        && ((other.minor > current.minor)
            || (current.minor == other.minor && other.patch > current.patch)))

Can you share more about why 0.y.z versions don't treat minor increments as compatible bumps?

@jaemk
Copy link
Owner

jaemk commented Aug 2, 2022

This is to mirror what cargo-update considers a compatible bump. For versions < 1.0.0, minor changes 0.2.0 -> 0.3.0 are considered breaking in the same way changes from 1.0.0 -> 2.0.0 are

@aharpervc
Copy link
Author

This is to mirror what cargo-update considers a compatible bump. For versions < 1.0.0, minor changes 0.2.0 -> 0.3.0 are considered breaking in the same way changes from 1.0.0 -> 2.0.0 are

Interesting... Is that part of the semver spec, or something cargo-update is doing on their own separately?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants