Lockfile inconsistent with cargo config

[alerque]

The v0.10.0 release does not build cleanly from source because the Cargo.lock file is out of date with the contents of dependencies in Cargo.toml.

Please even if you don't update the lockfile when updating dependencies (which I would recommend) at least update it before tagging releases.

[MultisampledNight]

Thank you! Sorry for the inconvenience, I know that's a problem in frozen environments. I've just run cargo update and bumped the version to 0.10.1, should that be in a new release or is a new tag enough?

[MultisampledNight]

I created a new release tagged 0.10.1 which includes that exact change.

[alerque]

Thanks. v0.10.1 is distributed to Arch Linux repos.

[alerque]

Just for the record (and anybody else wondering), the issue is not that it is super difficult to build a package without freezing to the lockfile (dropping the --frozen or running cargo update is enough to build), the issue is that the resulting package is unreproducable. Reproducable builds are important for lots of reasons, but among other things they prove that the binary software distributed by distros like Arch Linux have not been tampered with by the people who build packages (like myself). If we have to bump the lockfile at build time ourselves then somebody else (or in our case an automated system) that tries to duplicate my packaging from the same source will come up with a different binary. This will throw a warning and end users will not have any proof that I didn't tamper with the build. Some systems will even refuse to distribute anything that isn't reproducible. Arch hasn't gone quite that far yet but the status is tracked.