cargo: Bump dependencies to latest version #484
No reviewers
Labels
No Label
AdminAPI
Bug
Check AWS
CI
Correctness
Critical
Documentation
Ideas
Improvement
Low priority
Newcomer
Performance
S3 Compatibility
Testing
Usability
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Deuxfleurs/garage#484
Loading…
Reference in New Issue
No description provided.
Delete Branch "jpds/garage:cargo-bumps"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
cde822eeeb
to21fe5eb49f
23903c66d2
tod81ebd72e2
Thanks for this work. Just one note: for
rmp-serde
, for now I avoided bumping it because it is possible that with new versions the way it serializes Rust structs changed slightly, which would cause incompatibilities in the storage format. If you really want to update it, please make a migration test from an existing Garage installation in a previous version and check that all data is still readable with the updated rmp-serde. But the simplest would probably be to keeprmp-serde v0.15
as it has been working great for us and this way we are sure not to cause any additional issues.166e82c72b
toe3526dfca4
@lx I too was sceptical on that one, but I found that they just defauled to string variants anyhow: https://github.com/3Hren/msgpack-rust/pull/286
The other function garage uses they declared "pointless":
2bef91ec4e
I've pulled it for now, but it can be cherry-picked from
d81ebd72e2e074687ba94d370e4d0d7b69581b82
Out of curiousity, I deployed two
v0.7.3
garage instances onto my laptop - clustered and uploaded a single file to them. I then performed the migration steps with this branch + thermp-serde
commit and was able to retrieve that file from them. 👍I'm happy with shipping the
rmp-serde
update.Changes requested in how we use the new base64 API, see below.
Also, can we move the rmp-serde upgrade to a separate PR ? This way we will integrate it in Garage 0.9, which will go through a lot of testing anyway, and the other crate updrades that aren't so critical can go into 0.8.2
@ -37,0 +36,4 @@
general_purpose::STANDARD
.decode(vs)
.ok_or_bad_request("Invalid base64 value")?,
),
Looks like we can do the following:
which allows this to be written more nicely as:
Same for all occurrences below
@ -42,3 +44,3 @@
}
base64::encode_config(bytes, base64::URL_SAFE_NO_PAD)
general_purpose::URL_SAFE_NO_PAD.encode(bytes)
e071145bac
to3dc655095f
LGTM. Try merging this commit to have the correct
Cargo.nix
that should make the CI work:a6534b5881
Thanks!