-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Release Cargo 1.0 #4211
Comments
The question of how Cargo's version number ought to track rustc's has been raised. To make it easier on users, IRC has proposed syncing Cargo's version number with rustc's, so instead of a 1.0 release it would actually be a 1.19 release (er, optimistically speaking, that is). This raises two further minor questions:
|
In my mind it's impossible for Cargo to have any sort of breaking change at this point in the normal sense, it's got the exact same stability story and guarantees as rustc itself. Along those lines this would be a purely cosmetic change, just changing a few version numbers here, I think we have no leeway to proposing any change to Cargo that we wouldn't already be comfortable proposing. Cargo-as-a-library will never be stable and will continue to publish a new major and breaking version each release of Cargo, we're not at all ready to provide any guarantees there. I would personally lean towards just making cargo's and rustc's version the same, less numbers to think about. That means, however, Cargo-the-CLI-tool and Cargo-the-library would have different versions. |
@alexcrichton today Carol was telling me that she might still have some potential breaking changes in mind for some of the CLI options, or at the very least would want to do an audit of the CLI before we stabilize it. Don't really know what that specifically entails or how extensive the changes she has in mind are. I think it's reasonable to have Cargo-the-tool have a stable version number while itself depending on an unstable "libcargo" or somesuch. |
One such breaking change is to change `cargo new` to be `cargo new --bin`
instead of `cargo new --lib`.
…On Fri, Jun 23, 2017 at 3:57 PM, Ben Striegel ***@***.***> wrote:
@alexcrichton <https://github.com/alexcrichton> today Carol was telling
me that she might still have some potential breaking changes in mind for
some of the CLI options, or at the very least would want to do an audit of
the CLI before we stabilize it. Don't really know what that specifically
entails or how extensive the changes she has in mind are.
I think it's reasonable to have Cargo-the-tool have a stable version
number while itself depending on an unstable "libcargo" or somesuch.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#4211 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABsioa07ndwZ7E1YV7rKKusQ8TiaqcHks5sHBimgaJpZM4ODAKQ>
.
|
I do realize that "moving to 1.0" sounds like a tempting time to make a bunch of changes, but the fact of the matter is that Cargo's stable right now. Any intention to change behavior I believe would require a transition plan regardless of Cargo's version number. We could do a scrutiny leading up to 1.0, but not being 1.0 doesn't buy us any extra leeway in my opinion. @steveklabnik I'd actually imagine that could change at any time! |
So for example, deprecating
I continue to maintain that the way you say "major version" meaning the x in 0.x when the leading version is 0 is confusing because that's not how the spec defines "major version" :P |
👍 for making Cargo binary to use the same version as Regarding the stability of Cargo CLI, I wouldn't say that the whole CLI is a public API (it's public, but it isn't necessary an API), so changing CLI without major version bump seems acceptable to me (provided that we are sure that it causes minimal amount of hassle in practice). To me, stability means that old code continues to work as it always used to. So as long as Cargo.toml, Cargo.lock, and crates.io registry are "stable" and any package can be used as a dependency, even if it was published long ago, I would say that Cargo has stability. In contrast, I don't see changing That said, Cargo is effectively stable, so imo we should mark it as |
What about renaming Cargo-the-library to something like |
@carols10cents oh I'd imagine we could change a flag like @matklad I think you and I are basically in agreement on the CLI aspect. I push back a little on the |
@steveklabnik if you want that functionality, you can always use a shell alias, or a dedicated too that makes templated projects. |
after chatting with @carols10cents about this, and given the current (carol is putting this on the cargo team proactive list ✨ ) |
We've discussed this at today's meeting, and decided that we change the version of the binary so that At the same time, we make no commitment to the stability of Cargo the library, and we continue to use the weird |
Make cargo-the-binary version the same as the Rust version Closes #4211 which seems stuck :-) Soooo, this is the simplest possible fix to this problem: ``` ~/projects/cargo Cargo-the-tool-1.0 λ rustc --version rustc 1.24.0 (4d90ac38c 2018-02-12) ~/projects/cargo Cargo-the-tool-1.0 λ cargo --version cargo 0.25.0 (8c93e08 2018-02-01) ``` It makes `cargo --version` to print the corresponding Rust version (with possibly cargo-specific patch number), while keeping the library version the same as today. On the one hand, this is horrible. On the other hand, it seems to do the job? In the long term, it would be cool skip one version bump for the library, so that `0.x` corresponds to `1.x`. cc @rust-lang/cargo I am not sure that this is good idea, the implementation certainly feels horrible :)
Our initiative towards stability for the Rust ecosystem this year ought to encompass tooling as well, especially crucial tools that are shipped with the compiler. I only just realized that Cargo was pre-1.0 by reading an article listing the precise versions of each tool it uses ( https://medium.com/@ianjsikes/get-started-with-rust-webassembly-and-webpack-58d28e219635 ); seeing "version 0.19.0" gives a mistaken impression as to the stability of Cargo which AFAIK shouldn't have breaking changes at all by now (at least not to the CLI), and given Cargo's close association to rustc it reflects poorly on Rust's stability as well. Is this simply a matter of bumping the version number to 1.0? If not, then edit this text to turn this into a tracking issue for Cargo 1.0.
The text was updated successfully, but these errors were encountered: