RFC 3283: Backward compatible default features by tbu- · Pull Request #3283 · ru...

The problem that this RFC solved can already be solved with semantic versioning, isn't it? Adding a new default-feature in a crate could be seen as a breaking change (for users having default-feature=false).

Unless I'm missing something, I feel using semantic versioning with a new major version should be mentioned in the Alternatives section at the very least.

yeah but you can just go turn on the feature and you're back in business, so it's not a big deal.

The problem that this RFC solved can already be solved with semantic versioning, isn't it? Adding a new default-feature in a crate could be seen as a breaking change (for users having default-feature=false).

Semantic versioning isn't a solution to this. Semver-incompatible changes should generally be avoided, almost at all costs. This is evidenced by the standard library which also has this very problem and will definitely not consider breaking semver to introduce a new on-by-default feature.

This is evidenced by the standard library which also has this very problem and will definitely not consider breaking semver to introduce a new on-by-default feature.

The standard library is a special case. There are a handful of core crates in the ecosystem that really must avoid semver breaking changes, but in most cases it's entirely possible to release new major versions with the only downside being a period of extra build time because of the duplicated crates until everyone updates.

Another perspective on this RFC is that it is adding another dimension to semantic versioning. We have a breaking version number at the package.version level but now we also have breaking version number package.feature-bases level.

The intended value of this feature is allowing decomposing the breaking version number into smaller pieces to offer users some extra stability as changes are made. This is somewhat similar to the case of a crate providing a subset of the API in "core" crates and us merging #3243 to allow better composing of these crates that would normally be re-exported.

The question for me is whether it pulls its weight when considering

• benefits of avoiding bumping the breaking version in package.version
• Scope and impact of crates needing versioned "default/default-features-false`
• users learning to deal with another "version"
• users managing another "version"

The standard library is a special case. There are a handful of core crates in the ecosystem that really must avoid semver breaking changes, but in most cases it's entirely possible to release new major versions with the only downside being a period of extra build time because of the duplicated crates until everyone updates.

I disagree. Every crate should strive to maintain backward compatibility unless there's some very good reason not to. Of course, it's possible to release a new major version, but it comes with the significant disadvantage that reverse-dependencies needing to upgrade, and sometimes that traits and types from major versions are incompatible without using the semver trick.

I disagree. Every crate should strive to maintain backward compatibility unless there's some very good reason not to. Of course, it's possible to release a new major version, but it comes with the significant disadvantage that reverse-dependencies needing to upgrade, and sometimes that traits and types from major versions are incompatible without using the semver trick.

Yes, every crate should follow semver in that a breaking change bumps the major version.

Now how much crates avoid bumping major versions is dependent on scope/impact. Some crates serve as "vocabulary terms", meaning they are core to cross-crate communication, like regex, tokio, etc. These need to minimize major version bumps due to splitting the ecosystem.

However, most crates don't fall into that category get used more directly and have little interop, reducing the impact of a breaking change. nom is a great example of this. Unnecessarily burdening these crates with pressure to not bump major versions can have a major dampening effect on the Rust ecosystem from growing.

I would just like to point out that a feature base is the same as a feature. If we required the feature list to never be empty (e.g. if no default features had to be used with at least one feature) we wouldn't have this problem.

I'm happy to admit maybe their are simpler solutions than my old RFC (which frankly I had all but forgotten about) but it would be nice to e.g. in a future edition have a simpler Cargo.toml spec.

We've discussed this in a few @rust-lang/cargo meetings. In particular, we're especially not in favor of the idea of having the version specified in Cargo.toml affect feature resolution, as opposed to the version actually selected by the resolver.

In general, we feel like we're favoring an approach more like rust-lang/cargo#3126 rather than this approach. (That still needs some details worked out, though.)

@rfcbot close

Team member @joshtriplett has proposed to close this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

In general, we feel like we're favoring an approach more like rust-lang/cargo#3126 rather than this approach. (That still needs some details worked out, though.)

It seems to me that the approach outlined in the linked issue will not allow people (or the standard library, for that matter) to add new features for existing functionality, because it only adds a way to specify dependencies. This means that you cannot make more parts of your library optional without it being a breaking change, because people might rely on their default-features = false build compiling.

In general, when adding a new default feature to a crate, there seem to be two cases:

1. The feature can be used (by deselecting it) to disable already-existing functionality. In this case, existing crates not knowing about the feature should keep it enabled.
2. The feature can be used to add new functionality. In this case, existing crates trying to disable default features and not knowing about the feature should probably have it disabled as well.

The current default-features = false enables use case 2, the linked issue would enable use case 1 if default-features = false were to go away, but this will never be the case (as I understand it). This means the linked issue will not actually enable library creators to use default features in a new way. default-features = true cannot work with use case 1 (it'll result in a compiler error) and the linked issue cannot work with use case 2 (it'll result in feature bloat).

In particular, we're especially not in favor of the idea of having the version specified in Cargo.toml affect feature resolution, as opposed to the version actually selected by the resolver.

I see. I think this makes sense. I think it also implies that not both of the use cases 1 and 2 can be satisfied at the same time.

This is now entering its final comment period, as per the review above.