possible sem-ver breaking update in temporal-rs 0.0.11 and timezone_provider 0.0.14 -> 0.0.16 affecting cargo update

[solomoncyj]

error: unexpected end of macro invocation
  --> /home/solomoncyj/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/temporal_rs-0.0.11/src/tzdb.rs:60:1
   |
60 | timezone_provider::iana_normalizer_singleton!();
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing tokens in macro arguments
   |
note: while trying to match meta-variable `$providername:ident`
  --> /home/solomoncyj/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/timezone_provider-0.0.16/src/./data/iana_normalizer.rs.data:6:6
   |
 6 |     ($providername:ident) => {
   |      ^^^^^^^^^^^^^^^^^^^

error: could not compile `temporal_rs` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...

this issue was observed when building and then not performing a locked build of https://github.com/denoland/deno/

old

timezone_provider v0.0.14
└── temporal_rs v0.0.11
    └── ry_temporal_capi v0.0.11-ry.1
        └── v8 v140.2.0
            ├── deno_core v0.363.0
            │   ├── deno v2.5.6 (/home/solomoncyj/Downloads/deno/cli)

after cargo update

timezone_provider v0.0.16
└── temporal_rs v0.0.11
    └── ry_temporal_capi v0.0.11-ry.1
        └── v8 v140.2.0
            ├── deno_core v0.363.0
            │   ├── deno v2.5.6 (/home/solomoncyj/Downloads/deno/cli)

[nekevss]

Hi! Thanks for submitting this.

Unfortunately, I'm not entirely clear on a good way to fix this besides deno and ry_temporal_capi bumping the version to temporal_rs 0.1 and being careful with running cargo update. @Manishearth do you know of a way to fix this in retrospect?

I think this may be a bug / idiosyncrasy of cargo and cargo update. In version 0.0.11 and the rest of the 0.0.x release, we specified the dependency as ~0.0.x for timezone_provider. Because we were pre-0.1 and this is a 0.0.x version bump, cargo should treat these version changes as a breaking and not a patch bump, but I guess cargo treats all 0.0.x version changes as patch bumps.

For our part, we should not have used a tilde when specifying the version below 0.0.x, and we should definitely double check the current way we define versions in our Cargo.toml for our current releases.

But it is surprising behavior that 0.0.x bumps are treated as patch bumps.

[Manishearth]

Yeah, we shouldn't be using tilde deps. I don't see a way to fix it in retrospect.

Note that v8 has since updated to temporal_rs 0.1

[nekevss]

Follow up, it does look like rusty_v8 upgraded to temporal_capi v0.1 in denoland/rusty_v8#1863. So this should be fixed in future releases of deno with rusty_v8 v142.0.0