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


#21

Cargo has dropped support for old versions of Rust: https://github.com/rust-lang/cargo/commit/ca1377214a9b1022dce4ccfd92049f35075fbf5e


#22

Thanks for that link!


#23

Ubuntu LTS has a support life span of five years. If we continue to compile 95% of crates every half year, extrapolating that over five years gives a 60% success rate, i e, 40% of programs stop compiling. That’s quite terrible for a stable distro; bring it down at least, say, two orders of magnitude before even considering it.

I think the “No privates in public” improvement is a good example of something I would not let into a stable distro. We allow that improvement, because improving and perfecting the language is - although we’re past 1.0 - more important than not breaking code. There was also an asref regression recently (issue 30744) which was just dismissed as “acceptable breakage”. As long as this is our policy, I would not update Rust to a newer version in an already stable distro.

(Btw - I don’t know of any case when Ubuntu has updated a compiler at all in a stable distro. Possibly Ubuntu would do so if there was a CVE for the compiler itself, and then that CVE would be fixed and nothing else.)


#24

This sounds like an chicken-and-egg problem: the current rate of breaking changes in rustc makes it very unlikely that someone even attempt making a 1+ million line Rust code base. How big is servo, btw?


#25

Especially because “compiles” is not “works”. Also, subtle regressions are a thing. Note that rustc’s “no breakage” guarantee does not cover performance regressions.

It’s a tough topic. I tend to encourage my clients to often update if the software in question has a fast release cycle. Changes are smaller and breakage is easier to pinpoint. But software with large surfaces can lead to problems. I often consult on Elasticsearch and it’s not unusual that high-profile users meet subtle bugs on a regular basis which merit changes on the system, which in turn makes upgrading expensive.


#26

I don’t think extrapolating this works. We should be worse at first, but better eventually.

Pretty much all languages include small breaking changes in new releases; I still think Rust is ultimately better than the average in this regard.


#27

The exact 95% stat is pretty dubious anyway, counting each crate version separately etc (there will be some correlation there).


#28

Better as in “at least two orders of magnitude better”? I doubt it, but it remains to be seen.

Yeah, GCC 6 seems to be causing several build failures, e g. So much more the reason not to backport new compilers to stable distro releases.

It’s one thing if think of your compiler as “just another app”, where you want the latest features as soon as possible. It’s another when the compiler is a critical part of your distro infrastructure, what must work without failures when you fix critical bugs (which you need to quickly release to your millions of users).

IMO, the amount of breaking changes during the last half year is a sign that Rust is not yet mature enough to be a critical part of a distro’s infrastructure. I hope it will be, some day.


#29

I believe the number of breakages we have had on stable release, and the trade-offs that have been made are pretty much right.
The number of breakage will gradually decrease.
Rust-lang is a “breaking change” itself to C/C++ based on that the breakage is a better choice against sticking with bad design/implementation indefinitely for the sake of “stability” in the long run.
Given said that, breaking changes are not created equal. The deprecation process we already have can alleviate the pain. You get the warning before hand, and are offered advice on how to change your code to avoid breakage on your next compiler upgrade.

The fear of upgrading because of breaking changes in the industry means breaking change process can be improved upon (both from the language/library perspective or from the company process perspective) but not we should refrain from upgrading because of breaking change, or not making justifiable breaking changes if we need to.

As for the topic itself, I think a minimum rustc version tag for a given version crate seems to be a good starting point to have a better view and measurement of this issue.


#30

Depending on what you consider to be part of Servo, over half a million source lines of Rust code.

Since sloccount doesn’t support Rust, find -name '*.rs'|grep -v /target/|xargs cat|wc -l counts 187 859 lines in the servo/servo repository.

But a lot of Servo is not in the main repository, and we regularly extract crates when people say they want to use them outside of Servo. In the 73 repositories that I have on this machine (usually because I submitted a pull request at some point) for a subset of Servo’s dependencies, that number is 399 608 lines.

These add up to 587 467 source lines of Rust code. Note that this ignores non-Rust code (Servo has some large C/C++ components) and generated Rust code.

(For comparison, the rust-lang/rust repository has 583 258 lines with the same counting method.)


#31

Breadcrumbs for future searchers: there is an open RFC to have rust-lang-nursery crates support current stable plus the two previous stable releases.