Skip to content
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

Closed
emberian opened this issue Jan 8, 2014 · 7 comments
Closed

Comments

@emberian
Copy link
Member

emberian commented Jan 8, 2014

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
Copy link
Member

pnkfelix commented Jan 9, 2014

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
Copy link
Contributor

brson commented Jan 9, 2014

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

@pnkfelix
Copy link
Member

pnkfelix commented Jan 9, 2014

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

bors added a commit that referenced this issue Jan 22, 2014
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
bors added a commit that referenced this issue Jan 24, 2014
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
@brson
Copy link
Contributor

brson commented Apr 3, 2014

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

@emberian
Copy link
Member Author

emberian commented Apr 3, 2014

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
Copy link
Member

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
Copy link
Collaborator

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

flip1995 pushed a commit to flip1995/rust that referenced this issue Sep 7, 2023
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants