-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Semantically version the language specification, compiler, and libraries #11396
Comments
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? |
This seems to cover a lot of different topics. We probably need to document our stability strategy for: APIs, language, tool interfaces. |
(Deferring assigning a P-tag until task is clarified. Re-nominate once that is done, if necessary.) |
This patchset consists of three parts: - rustpkg doesn't guess crate version if it is not given by user. - `rustpkg::version::Version` is replaced by `Option<~str>`. It removes some semantic versioning portions which is not currently used. (cc #8405 and #11396) `rustpkg::crate_id::CrateId` is also replaced by `syntax::crateid::CrateId`. - rustpkg now computes hash to find crate, instead of manual filename parse. cc @metajack
This patchset consists of three parts: - rustpkg doesn't guess crate version if it is not given by user. - `rustpkg::version::Version` is replaced by `Option<~str>`. It removes some semantic versioning portions which is not currently used. (cc #8405 and #11396) `rustpkg::crate_id::CrateId` is also replaced by `syntax::crateid::CrateId`. - rustpkg now computes hash to find crate, instead of manual filename parse. cc @metajack
cc #13289, which I think identifies more clearly the biggest problem. |
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). |
One teeny note: other than the patch things, we ARE already following SemVer. 0.x.y is 'anything goes,' so we're good. |
This issue has been moved to the RFCs repo: rust-lang/rfcs#303 |
new lint: `iter_out_of_bounds` Closes rust-lang#11345 The original idea in the linked issue seemed to be just about arrays afaict, but I extended this to catch some other iterator sources such as `iter::once` or `iter::empty`. I'm not entirely sure if this name makes a lot of sense now that it's not just about arrays anymore (specifically, not sure if you can call `.take(1)` on an `iter::Empty` to be "out of bounds"?). changelog: [`iter_out_of_bounds`]: new lint
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.
The text was updated successfully, but these errors were encountered: