Pros and Cons of Versioned Crate Features?


#1

I’m considering using versioned crate features. For example, for the crate to enable serde support, it would have a crate feature named “serde-1” for that which corresponds to a dependency on serde 1.0.

The arguments:

  • Break the namespace pun. The crate feature is separate from the optional dependency.
    • This makes it possible to change what dependencies the feature maps to
  • Version the crate flag
    • This makes it possible to support both serde-1 and the hypothetical serde-2 at the same time (if there is some way to disambiguate the dependency, and there is)

Maybe you think this doesn’t matter anymore. This is what I wish I had done during the pre-1.0 evolution of serde, so it would be applying a conclusion from the pre-1.0 time to the 1.0 reality. I still don’t see why not to do this.


#2

I think the argument for not doing this would be that it will be hard to predict the differences between v1 and v2 such that it would be easy to disable one in favor of the other.

Also, is it possible to version dependencies in the feature? Or will you need an intermediate serde1 crate?


#3

It would need an intermediate crate yes. But the breaking of the name pun means that it can be postponed until / if it’s needed. No need to set up separate crates at the start.