Rust version support in library crates: "best practices"?


#1

What’s the community’s thoughts on older Rust versions in library crates? Eg, at the moment, nix supports 1.1+, and there’s a GitHub issue attempting to figure out an explicit version support policy. I can see reasonable arguments both for maintaining support for older versions, and for quickly adopting new language and library features as they’re added to stable releases.

Is there anything like a consensus here? Does it make sense to try and support older versions of Rust? Are there any considerations that would depend on what the library does?


#2

I personally support one-version back (i.e. rust 1.5 right now) for existing stuff and don’t count bumping the minimum supported version as a breaking change. Some other crates like libc and log try more aggressively to stay at old rustc versions.

I imagine the story will get more complicated when rustc starts ending up in package repositories for Ubunto LTS or CentOS or whatever, since there’ll be people stuck on old versions of rustc at that point. Crate developers will probably have to start being more conservative at that point.


#3

Some best practices:

  • Document which Rust versions are supported
  • Use CI to test at least that version

#4

Yes, that’s one issue.
Another issue is that some companies(usually bigger ones) start with a technology and never change to a newer version because they are afraid of breakage.
At the company I work, we use GCC 4.4.1 and Qt 5.2.1 exactly because of this reason.
And you would like to work with new features(in this case, C++11, C++14, sanitizers…) but you can’t…
But at the same time, those kind of companies probably would sit on the version of the library/framework they started with(for example Qt 5.2.1).

Back to distros packaging issues:
What Rust needs in distributions like Ubuntu is to be released the same way Firefox is released…


#5

Could you elaborate?


#6

That’s quite interesting. Sounds like there might be some implicit consideration around “universal applicability” going on? Both those crates are pretty low level and likely to be used by a wide range of others.


#7

One reason to stay on older Rust is if you plan on becoming a dependency of Cargo; it has picked 1.2, IIRC, as its minimum version.


#8

Firefox is treated somewhat unusual by Ubuntu, in the sense that new Firefox versions are released into stable versions of Ubuntu. I don’t know all the details behind that decision, but I assume the fact that Mozilla does not fix security issues for old versions would be a contributing factor.

Given the current rate of breaking changes in rustc, I would advise against giving rustc the same treatment.


#9

I think it’s a huge waste of time to support older versions of Rust and I only support the latest Stable, Beta, and Nightly versions in my crates. I seriously doubt there is anybody using Rust that can’t afford to (and hasn’t budgeted) one day every six weeks to make their code base compatible with the latest release.

If an important project decides to institute some kind of backward-compatibility policy, then they’ll apply pressure to the libraries they depend on to adopt a similar policy. This kind of policy then kind of spreads like a virus. But, what is the worse problem: a huge shortage of libraries with important functionality, or saving people ~1 day per six weeks? I would very much rather have library authors spending time adding functionality and/or otherwise improving their library, than maintaining backward compatibility for versions older than the current stable version.


#10

We should not be making breaking changes to the stable compiler. There have been one or two soundness holes fixed, but over 90% of post 1.0 code still builds on 1.5. What rate of change is appropriate here?


#11

Where can I find docs for old versions of std? My PR to Cargo has just failed CI for rust 1.2 =(


#12

Actually, most of serious code can’t afford this. When you have millions of lines of code you definitely do not want this.
Especially in big companies where there are so many teams that everything moves to slow.
In that case, when something breaks in nightly, porting can be started so when it reaches stable everything is finished.
But if it changes often, no one would want this. It’s not ok to focus on fixing incompatibility instead of focusing on developing your software.


#13

http://doc.rust-lang.org/1.2.0/


#14

At this stage in Rust’s life cycle, I would recommend that you keep the latest version of your library working with the latest version of Rust. If someone wants to move forward to the latest version of your library then they can spend the time to come up to the latest version of Rust since they’ve already committed to a migration/regression test.

If you bug fix an older revision of your library then that fix should probably work with the version of Rust it was released on, i.e. don’t use new rust traits.

When/if(?) Rust moves to a 6 month or longer release cycle, I’m assuming the APIs would have really stabilized at that point and there is less danger of a dependent interface going away so it would be easier to support older versions of Rust. At that point you can re-evaluate the version support.


#15

I would say support the oldest version that you can support without too much effort. Then don’t change the minimum Rust version on bugfix releases (and if you do a feature release that includes bugfixes, backport the fixes).

I did face this dilemma: get deprecation warnings on every build (with a recent compiler) and be compatible with Rust 1+, or require a newer Rust version just to get rid of the warnings even though the code was working fine? What I opted for is to require a newer Rust version with the next feature release of my library.


#16

You can also suppress warnings (example from cargo https://github.com/matklad/cargo/blob/metadata2/tests/support/mod.rs#L352)


#17

As a user of the compiler, I disagree. Especially, I would prefer the soundness holes to be fixed in a timely manner and for the formal semantics of the language to be developed so that formal analysis/proofing tools can be developed and then used. If making breaking changes helps in either of those respects, please break the compiler as frequently as necessary.


#18

Who has a 1+ million line code base in Rust? I would love to talk to them.


#19

I think you misunderstood me. That’s exactly our policy already.


#20

Yes, I guess I put too much emphasis on the “We should not be making breaking changes to the stable compiler.” part and not enough on the rest. Thanks!