Consider making the `version` field optional in Cargo.toml

[matklad]

Describe the problem you are trying to solve

Today, the version field is required. However, in many (most?) cases it doesn't make sense:

• when doing some casual rust hacking for fun or learning
• inside "live at HEAD" company monorepo
• when working on a large Rust projects not distributed via cargo install

This creates specific issues:

• additional confusion -- there is a line in Cargo.toml which is there "just because", and not due to some specific reason
• diluted meaning of versions: semver compatibility is a lot to promise, by having versions everywhere it's harder to notice where they matter and where you need to care about API compatibility
• For projects which mix published and non-published crates in the same source tree, it becomes harder to know at a glance if a particular crate is published.

Describe the solution you'd like

Make the version field in Cargo.toml optional. Do populate it by default, as it is today. Prevent publishing the crates which (transitively) depend on non-versioned crates.

Notes

There is publish = false, to my mind that serves a different purpose -- preventing accidental publishing of the crates. It doesn't help with solving confusion problem -- the version is still there, and it still doesn't have a meaning. Although, if we were to re-design Cargo from scratch, I would argue that we shouldn't have publish field at all, and insead define it as publish = version.is_some().

Implementation wise, it seems like we can desugar absence of version as version = "0.0.0" publish = false. I personally use version = "0.0.0" as a way to explicitly signal that there's no meaningful version.

[probablykasper]

In my case I have a rust project that is just part of an Electron app. My package.json already has the version, so the Cargo.toml version field is just unnecessary and confusing.

Having a version can still be useful even if you have publish = false. In npm, the version field is optional, and you'll get warnings unless you have the equivalent of publish = false

[hwittenborn]

In my case I have a rust project that is just part of an Electron app. My package.json already has the version, so the Cargo.toml version field is just unnecessary and confusing.

I have the same issue for something I solely distribute as a .deb package - my main issue is that I have to update the version in both my Debian packaging files and in my Cargo.toml, which is quite tedious and has been error-prone in my setup.

At the least it would be nice to able to simply overwrite the version during a build via a CLI flag. Even if the version key didn't have to be present, it would still be ideal to have that so my program could determine the proper version to set in things like a --version menu.

[tshepang]

I think the most simple solution is for cargo new to set initial version to 0.0.0 (instead of 0.1.0).

[hwittenborn]

I think the most simple solution is for cargo new to set initial version to 0.0.0 (instead of 0.1.0).

This isn't really an issue with what the default version is, but just how to have no version at all. I think that argument merits its own issue imo.

[epage]

cargo script (#12207) is defaulting the version to 0.0.0 for scripts. To close the gap between a cargo script and Cargo.toml, I think it'd be worthwhile to implement this issue. My main concern is with the implications through the rest of cargo, mostly pkgid. For CARGO_PKG_VERSION and friends, I would just not populate them.

[jplatte]

Even outside cargo script, I find that having to add publish = false and keep a meaningless version around is pointless boilerplate. I don't think there should be a lint about a missing publish = false if the version is absent; it will be obvious when attempting to publish that it's not possible because of the missing version (writing a descriptive error message should be simple) and adding one at that point is simple as well. Maybe Cargo could / should lint if publish is set [to something other than false] and the version is unset though.