Clarity around versions. Does counting start at zero? Or at one? Why is "0.1.0" the first version?

[aaelony]

cargo new myproject produces a Cargo.toml file with version="0.1.0".

I always edit this manually to be version="0.0.1" when I create a new project.

Why should a new project immediately be bumped to "0.1.0" ? Either the counting starts at zero or it starts at one, but it should be consistent. Maybe it should be "0.0.0"?

https://semver.org/ does not appear to address this.

[weihanglo]

I think it strikes a good balance between

• You can have minor version bump without breaking changed, like 0.1.1 and 0.1.2 should be SemVer-compatible (in Cargo's sense of Semver).
• You are not marketing it as "1.0". 1.0 usually means it is production ready. 0.1 gives more rooms to iterate.

Also, you can leave off the version field completely, it defaults to 0.0.0 when omitted since 1.75.0 (#12786).

I am not sure if the rationale needs to be documented. It is more like an opinionated choice and people may have different thoughts. And after all, cargo new is just a simple template for people to start with. The general project templating is discussed and tracked in #5151. What and where you think we should/could document this?

[aaelony]

I am using $ cargo --version cargo 1.86.0 (adf9b6ad1 2025-02-28) which defaults to 0.1.0 not 0.0.0 .

$ cargo new testing
    Creating binary (application) `testing` package
note: see more `Cargo.toml` keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
$ cat testing/Cargo.toml 
[package]
name = "testing"
version = "0.1.0"
edition = "2024"

[dependencies]

[weihanglo]

Also, you can leave off the version field completely, it defaults to 0.0.0 when omitted since 1.75.0 (#12786).

To clarify, it is not about the generated project template from cargo new. It is about when the default value of the version field when not set. See The version field:

This field is optional and defaults to 0.0.0. The field is required for publishing packages.