Prepare for release 2.3.1

[Robbepop]

• Write changelog
• Bump crate versions from 2.3.0 to 2.3.1.

[gui1117]

I'll merge and publish once CI is done

[Robbepop]

A run of cargo outdated -vvv shows that quite a few dependencies are outdated.
Amongst others the bitvec crate that caused problems has had 2 new minor version updates.
We could push out another minor version after this patch version with the updated dependencies. What do you think about this?

Name                                              Project  Compat   Latest   Kind    Platform
----                                              -------  ------   ------   ----    --------
atty->libc                                        0.2.101  0.2.103  0.2.103  Normal  cfg(unix)
bitvec                                            0.20.4   ---      0.22.3   Normal  ---
bitvec->funty                                     1.1.0    ---      1.2.0    Normal  ---
bitvec->wyz                                       0.2.0    ---      0.4.0    Normal  ---
byte-slice-cast                                   1.0.0    1.1.0    1.1.0    Normal  ---
clap->unicode-width                               0.1.8    0.1.9    0.1.9    Normal  ---
criterion->serde_json                             1.0.67   1.0.68   1.0.68   Normal  ---
csv->bstr                                         0.2.16   0.2.17   0.2.17   Normal  ---
derive_arbitrary->syn                             1.0.76   1.0.77   1.0.77   Normal  ---
getrandom->libc                                   0.2.101  0.2.103  0.2.103  Normal  cfg(unix)
hermit-abi->libc                                  0.2.101  0.2.103  0.2.103  Normal  ---
impl-trait-for-tuples->syn                        1.0.76   1.0.77   1.0.77   Normal  ---
js-sys->wasm-bindgen                              0.2.77   0.2.78   0.2.78   Normal  ---
num_cpus->libc                                    0.2.101  0.2.103  0.2.103  Normal  ---
parity-scale-codec-derive->proc-macro-crate       1.0.0    1.1.0    1.1.0    Normal  ---
parity-scale-codec-derive->syn                    1.0.76   1.0.77   1.0.77   Normal  ---
plotters->wasm-bindgen                            0.2.77   0.2.78   0.2.78   Normal  cfg(target_arch = "wasm32")
plotters->web-sys                                 0.3.54   0.3.55   0.3.55   Normal  cfg(target_arch = "wasm32")
serde_derive->syn                                 1.0.76   1.0.77   1.0.77   Normal  ---
textwrap->unicode-width                           0.1.8    0.1.9    0.1.9    Normal  ---
thiserror-impl->syn                               1.0.76   1.0.77   1.0.77   Normal  ---
tinytemplate->serde_json                          1.0.67   1.0.68   1.0.68   Normal  ---
trybuild->serde_json                              1.0.67   1.0.68   1.0.68   Normal  ---
wasm-bindgen->wasm-bindgen-macro                  0.2.77   0.2.78   0.2.78   Normal  ---
wasm-bindgen-backend->bumpalo                     3.7.0    3.7.1    3.7.1    Normal  ---
wasm-bindgen-backend->syn                         1.0.76   1.0.77   1.0.77   Normal  ---
wasm-bindgen-backend->wasm-bindgen-shared         0.2.77   0.2.78   0.2.78   Normal  ---
wasm-bindgen-macro->wasm-bindgen-macro-support    0.2.77   0.2.78   0.2.78   Normal  ---
wasm-bindgen-macro-support->syn                   1.0.76   1.0.77   1.0.77   Normal  ---
wasm-bindgen-macro-support->wasm-bindgen-backend  0.2.77   0.2.78   0.2.78   Normal  ---
wasm-bindgen-macro-support->wasm-bindgen-shared   0.2.77   0.2.78   0.2.78   Normal  ---
web-sys->js-sys                                   0.3.54   0.3.55   0.3.55   Normal  ---
web-sys->wasm-bindgen                             0.2.77   0.2.78   0.2.78   Normal  ---

All of these boil down to a single cargo update and shifting the dependency of bitvec to version 0.22.3.
However, updating bitvec yields tons of compile errors. Seems like non trivial work.

[gui1117]

I feel like for binaries it makes sense to have no outdated compatible version, but for libraries I think there is no need to be always with the latest compatible version, our library parity_scale_codec support both byte_slice_cast 1.0.0 and 1.1.0 there is no need to force our user to use byte_slice_cast 1.1.0 it is their choice to use any of the version.

That said maybe it is a good practice to do it anyway so that our test suite is run against the latest version.

For bitvec we are on the latest compatible version, and as we use it publicly (we implement codec on some of its type) then upgrading to a new major version is a breaking change and I would prefer not to release parity_scale_codec major version at the same (quite fast) rate as bitvec.
Maybe it is possible to implement multiple version with new feature (like we create a new feature bitvec-0-22) but feature in rust being usually annoying and limited (no feature on optional dependency etc..) I'm not sure it worth the pain.

To conclude I think it is not needed

[gui1117]

published with tags :-)