Semantically version the language specification, compiler, and libraries

[emberian]

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.

[pnkfelix]

The description indicates that we need to change our version specifier to use three periods (instead of just two). The team agrees with this.

But it is not clear what the scope of this bug is beyond that change. @cmr can you provide more detail, e.g. a list of the tasks you envision?

[brson]

This seems to cover a lot of different topics. We probably need to document our stability strategy for: APIs, language, tool interfaces.

[pnkfelix]

(Deferring assigning a P-tag until task is clarified. Re-nominate once that is done, if necessary.)

[brson]

cc #13289, which I think identifies more clearly the biggest problem.

[emberian]

Essentially we need to go through everything and determine precisely what we consider our stable public API. In particular the interface with the compiler needs specifying, since libraries and programs are basically taken care of (stability attributes + feature gates).

[steveklabnik]

One teeny note: other than the patch things, we ARE already following SemVer. 0.x.y is 'anything goes,' so we're good.

[rust-highfive]

This issue has been moved to the RFCs repo: rust-lang/rfcs#303