Backwards incompatible change in minor version bump from 4.1.3 -> v4.1.4

[cpcloud]

It looks like the bump from v4.1.3 -> 4.1.4 here (https://github.com/dermesser/yup-oauth2/compare/v4.1.3...v4.1.4) is a breaking change for dependent crates that use default-features = false.

With default-features = false, a crate that depends on yup-oauth2 will get neither hyper-rustls nor hyper-tls and thus will fail to compile.

I'm not entirely sure what there is to be done here. I wonder if it's worth yanking this version of the crate from crates.io?

[dermesser]

It looks like the bump from v4.1.3 -> 4.1.4 here (v4.1.3...v4.1.4) is a breaking change for dependent crates that use default-features = false

I'm sorry for the breakage, I didn't consider this case. Yanking and republishing as 4.2.0 is possibly the best way forward? I don't think this warrants a big jump, as this is technically a backwards-compatible change except if you on purpose disable default features. In my mind, if you do that, you already state, "I know better" and are then on the hook for selecting the right features, no? :)

Let me know if this would work for you.

[cpcloud]

this is technically a backwards-compatible change except if you on purpose disable default features.

I understand where you're coming from, but it's still a backwards incompatible change since the effect of setting default-features to false changed for the crate and dependents were affected without their code changing.

I don't think default-features = false is a way of saying "I know better", I think it's a way of saying "I want every feature to be opt-in" and doesn't have the implication of "you're on your own" :). So, if something that was previously not opt-in (the TLS client library in this case) becomes obligatory then it's a breaking change.

Yanking and republishing as 4.2.0 is possibly the best way forward?

For our usage of the library, we ended up just upgrading to yup-oauth2 = "5" and dealing with any other upgrades that were needed. I think yanking 4.1.4 and republishing 4.2.0 is probably fine, but curious what others think too.

[nagisa]

Yanking and republishing as 4.2.0 is possibly the best way forward?

As per cargo's use of semver for MAJOR versions >= 1 both MINOR and PATCH version bumps are required to be backwards compatible. In that respect publishing any 4.x.y version with this breaking change is a violation of cargo's interpretation of the semver rules.

if you on purpose disable default features. In my mind, if you do that, you already state, "I know better" and are then on the hook for selecting the right features, no? :)

A more common line of thinking here goes something along the lines of "I am making a library and don't want to be on a hook for transitively pulling dependencies my library doesn't require". That's how most of the uses of default-features = false happen in my experience.

A good way to avoid this situation in general would be to only have features that are always additive (that is, no mutually exclusive features) and that the library always builds without any enabled.

[nagisa]

https://doc.rust-lang.org/nightly/cargo/reference/features.html#feature-unification has some nice documentation and guidelines. A particularly nice option for yup-oauth2 may be selecting one feature over another by default if both are specified.