feat(cli/version): add canary versioning

[crowlKats]

No description provided.

[lucacasonato]

@crowlKats Doesn't seem to work:

[bartlomieju]

@crowlKats you need to add this line to build.rs:

println!("cargo:rustc-env=DENO_CANARY={}", env::var("DENO_CANARY").unwrap_or_else(""));

[crowlKats]

@lucacasonato i was wondering why it said 1.5.1 and was misisng the extra sutff like target tuple afterward... you are calling --version on the deno binary used for the CI itself, not the one that just got built.
Already found it weird that i needed to add the build.rs line as it was working fine locally without it

[lucacasonato]

@crowlKats Good catch. I validated that it works:

[lucacasonato]

I just realized that a canary for 1.6.0 would have version 1.5.4-hash with the current setup. It should really be 1.6.0-hash. We could fix this by setting DENO_CANARY env var to the next version (so 1.5.4 in cargo.toml, and 1.6.0 in DENO_CANARY env var). When updating the version, we would have to change both the cargo.toml, and the next version in the ci.yml file. WDYT?

[ry]

I just realized that a canary for 1.6.0 would have version 1.5.4-hash with the current setup. It should really be 1.6.0-hash. We could fix this by setting DENO_CANARY env var to the next version (so 1.5.4 in cargo.toml, and 1.6.0 in DENO_CANARY env var). When updating the version, we would have to change both the cargo.toml, and the next version in the ci.yml file. WDYT?

This seems like a lot of work and potentially error prone. I think 1.5.4-hash is fine for now.

[IllusionPerdu]

Since the next versions are not known during the releases, it suffices to specify in the documentation that the canary versions are that of the last release and that it is the hash that allows them to be distinguished.

[ry]

LGTM - thank you @crowlKats