1

I would like to create a multi-version crate. Say I creating crate for some standard, let's call it A and that standard has a couple of versions (1.0, 1.1, 1.3 ...). What I want is to create a crate were:

  • users could select the standard version they need,
  • I could work and fix bugs on each version in parallel,
  • ideally, I would like to have a single code base were version would be specified on the fields, modules or functions using comment or annotations.

Example:

/// since: 1.1
pub struct A {
    aa: String,  // since 1.1
    /// since: 1.2
    bb: String,
}

impl A {
    pub fn new() -> Self { ... }
    #[since: 1.3] // as an example
    pub fn from(other: &Self) -> Self { ... }
}

Users could use it as:

[dependencies]
a = "1.2"

or

[dependencies]
a = "1.1"

The idea is I could fix/improve the 1.1 implementation and version number still would stay the same even if here is version 1.2 released.

I never created Rust crate before, but I have a couple of ideas on how versioning could be done:

  1. have subversion number to each version eg 1.1.2 or 1.1-2 were 2 is 1.1 standard versions implementation version.
  2. to have a separate crate version and allow users to choose the standard version eg:
[dependencies]
a =  "0.7"

[dependencies.a]
standard = "1.1"
  1. other?...

I hope I explain good enough what I want to do. The question would be: The ways versioning could be done ideally with the link to the crates doing it (so I could see implementation)?

UPDATE:
After writing this question I find a UUID crate which is doing similar to what I need, But not exactly as each UUID version is as separate standard instead of an update of previous one.
I'm still curious is there any other ways to achieve multi-versioning?

my-
  • 604
  • 9
  • 17
  • 1
    You could use [conditional compilation](https://doc.rust-lang.org/reference/conditional-compilation.html), where you check for an option (say `standard_version`) that specifies what version of the standard a user of your crate wants to target. – EvilTak Jan 01 '21 at 15:29
  • @EvilTak unless multiple versions can be used concurrently, the "option" can / should probably just be a bunch of features (ideally they'd be mutually exclusive features, but cargo doesn't provide a way to do that so you'd need to hand-roll the compilation error). For instance [Inkwell](https://github.com/TheDan64/inkwell) "implements" multiple versions of a standard (LLVM), each LLVM version is a feature flag and you enable whichever feature matches the LLVM version you want to use. – Masklinn Jan 01 '21 at 15:51

0 Answers0