bump the version of croaring to 0.3.9

[antiochp]

Resolves #2693.

Bumps croaring to 0.3.9 which itself uses the latest croaring Unity build -
https://github.com/lemire/CRoaringUnityBuild

[ignopeverell]

Just to double-check, the underlying storage formats stay compatible, correct?

[antiochp]

Just to double-check, the underlying storage formats stay compatible, correct?

Good question - pretty sure yes, but I was making some untested assumptions here.
I will spend some time today testing a few different upgrade scenarios to make sure new code still reads the old local data etc.
I tested "fast sync" process but we do want to make sure a node can be upgraded in place safely.

Edit: Manual testing appears to confirm that these storage formats remain compatible.
There is nothing in the croaring release to indicate anything changed to contradict this.

[hashmap]

Do we have any specific reason to stick with exactly 0.3.9?

[hashmap]

In chain crate we don't use = to pin the version, even practically it's the same because we specified patch version, but I'd suggest to be consistent

[antiochp]

Oh good catch - I spent more than a few minutes staring at the = inside the quotes and the one outside the quotes and still managed to do this in an inconsistent way...

We should just specify it as croaring = "0.3.9" everywhere right?

And to your earlier point this is interpreted as "^0.3.9", i.e. would allow upgrade to 0.3.10 but not 0.4.0.
So yeah - there's no real point pinning it to an explicit version.

Edit: Actually is that correct? Or does ^0.3.9 allow an upgrade to 0.4.x?

[hashmap]

actually even0.3 would work, it would give now 0.3.9 (in Cargo.lock) and 0.3.10 (etc) on the next version bump. Cargo always takes the max version, I'm not sure what it chooses when we specify the exact semver like 0.3.9

[sesam]

*Just my $0.02 answer on a peripheral question on an old and already completed ticket... :)

tl;dr semver: When you don't really care about the version, specify as little as possible to clearly show you don't care about the details.
Example from above:

blake2-rfc = "0.2"
byteorder = "1"

Then when you do care about the version, you can use =x.y.z to lock to that version, or maybe if there is one upgrade you can't accept you could to "<not.acceptable.version"
In any other case I think it's best to stick with specifying as little as possible in Cargo, and ALWAYS commit the lockfile when something has changed.

If automatic tests are good enough, maybe have a day of the month, or a couple days after having stabilized a major release or similar PR and code-sync, where cargo update and any punted major code refactorings happen. That limits the time span and impact of any workflow disruption.

Anyway, have a great day and thanks for keeping grin humming along!