Bump parking_lot to 0.10

[NikVolf]

No description provided.

[NikVolf]

Took me a while to realise that it is different versions of parking_lot in substrate and parity-common

[ordian]

changelogs please?

[ordian]

Isn't that a breaking change for parity-util-mem?

[NikVolf]

Seems like no.

[ordian]

But that's public API. parity-util-mem::MallocSizeOf v0.4.2 is implemented for parking_lot v0.9.0, but parity-util-mem::MallocSizeOf v0.4.3 is not (as 0.10.0 is a breaking change to 0.9.0)

[NikVolf]

hmm technically yes, but it will require major bump just for everything
ok to me though

[ordian]

yeah, that's version bump creep is unfortunate, but we already have to do this e.g. for rand and other libs, so it's better to safe than sorry

[ordian]

sorry for being semver-nazzi, but this is a breaking change for all kvdb-* libs now :)

[NikVolf]

Now I think not.
How do you think it can break?
in previous example it could break because of implementation for parking-lot:0.9.0 gone missing, seems this is not the case here.

[ordian]

The way to think about breaking changes is imagine you bump a version of only this crate in a lib that uses it as a dependency, will the compilation of the lib break? In this case the answer is yes, because the lib uses parity-util-mem::MallocSizeOf v0.4.0 and e.g. kvdb-rocksdb v0.4.2, but kvdb-rocksdb v0.4.3 (if you bump it that way) doesn't implement it (as it implements parity-util-mem::MallocSizeOf v0.5.0) and hence it doesn't implement kvdb 0.4.0 etc, so you will get compilation errors.

[NikVolf]

This breakage can be avoided by requiring kvdb ^0.4.3 (which is default when requiring just 0.4.3) in kvdb-rocksdb

So if you upgrade one to latest, you are forced to upgrade another

[ordian]

sometimes you can upgrade to the latest breaking change easily, but it doesn't make the change non-breaking

sometimes you can't control all of your dependencies, imagine that parity-util-mem is a transitive dependency of some lib, so the lib can't just upgrade it by bumping in its Cargo.toml;
that way the lib will end up with 2 versions of parity-util-mem 0.4.0 and 0.5.0, which are incompatible

[NikVolf]

Why incompatible? If you use it directly, you use only one of the versions. If you don’t use it directly, you don’t care if they are duplicated :)

[ordian]

Well, KeyValueDBv0.3.1 inherits from parity_util_mem::MallocSizeOfv0.4.0

parity-common/kvdb/src/lib.rs

Line 112 in 996d370

pub trait KeyValueDB: Sync + Send + parity_util_mem::MallocSizeOf {

You don't bump the kvdb version here, but bump only kvdb-rocksdb to 0.4.3, so it no longer implements KeyValueDBv0.3.1, right? Now, if you bump kvdb to 0.3.2, then kvdb-rocksdb_v0.4.2 no longer implements that.

Also parity-util-mem has a feature of global allocator which we use in parity-ethereum, so having two versions there will probably not work.

But I feel like we've spend too much time debating on this issue already and it's easier to just bump the major versions :)

[ordian]

hy incompatible? If you use it directly, you use only one of the versions. If you don’t use it directly, you don’t care if they are duplicated :)

Imagine this code

#[derive(MallocSizeOf)]
pub struct Foo {
    foo: third_party_lib::implements_parity_util_mem::MallocSizeOf_v_0_4_0,
    bar: parking_lot::RwLock<Baz>,
    kvdb: Arc<dyn KeyValueDB>,
}

this will break

[NikVolf]

easier to just bump the major versions

Yeah, of course it is easier, I just thought if we could avoid this cascading bump spam

But seems like no way :)

stale

[ordian]

Thanks!

[ordian]

(also kvdb-shared-tests)

[NikVolf]

I imagine doing this for substrate crates if they go to crates.io @bkchr

The whole thing just to update parking_lot 0.9 -> 0.10