Semantically version the language specification, compiler, and libraries

[rust-highfive]

Issue by cmr
Wednesday Jan 08, 2014 at 04:57 GMT

For earlier discussion, see rust-lang/rust#11396

This issue was labelled with: A-versioning, B-RFC in the Rust repository

---

semver is a specification for version numbers and what they mean. Once we hit 1.0, I think we should start semver for everything, thus actually making it 1.0.0.

The "public API" we define would only consist of items marked #[stable] in the libraries. For the language, it would be anything not requiring a feature gate. For the compiler, it'd be output filenames and arguments, excluding -Z, --link-args, --linker, undefined lints, --lvm-args, --passes, and --ar.

Nominating.

[seanjensengrey]

@alexcrichton @DanielKeep continuing the conversation from #457 ...

I think having a version attribute required for each file for 1.0 would ensure that there is enough metadata out in the field for when a semantically breaking change does occur. I agree the logic is best handled outside of the compiler proper, but the metadata does need to be as close to the code as possible and as early as possible. No current language adequately addresses LTE (long-term engineering) and many languages that make breaking changes need to implement heuristics to determine the file type. C++ has arrived at its current position from enforced backwards compatibility, Python made breaking changes that could have been evolutionary but yet cleaved their ecosystem in the process, and Java had strictfp/assert/enum keywords added.

I think what #457 was getting at is, that we need files to carry their version information with them, without it, when a solution does arise, we won't have enough information available. If a file has no version, automatically assume it is 1.0? When 1.0 ships there will already be thousands of lines of pre-1.0 code in the wild, the problem already exists. I am not saying the compiler has to solve the problem right now, it just has to enforce that version information is supplied. The problem may very well it solved by Cargo, by managing multiple compiler versions. I don't do know what solution is, but I do know what information is required to solve it.

I'd like to be able to use Rust on a 500 KLOC codebase using versions 1 through 3.4 of the compiler and runtime over a 10 year period, with version 3.4 being just as fresh as the first.