Bump wincode-derive to 0.4.0

[cpubot]

This version includes the following bug fixes and features for wincode-derive:

• Support wincode(skip) in derive for fields #73
• Fix: fixed zero sized struct error #114
• Include SchemaRead/SchemaWrite bounds when deriving with generics #124
• add extra check in assert_zero_copy #146
• derive: SchemaRead ref constraints #150
• feat!: remove &mut from parameters passing Reader and Writer impls #152

Full commit diff

[steviez]

Is #124 a breaking change or will pre-existing bounds continue to compile ? Thinking about semver and wanting to make sure this should be 0.3.2 and not 0.4.0

[cpubot]

Is #124 a breaking change or will pre-existing bounds continue to compile ? Thinking about semver and wanting to make sure this should be 0.3.2 and not 0.4.0

Pre-existing bounds should continue to compile. For existing SchemaRead/SchemaWrite bounds, there may be conflicts, but I doubt anyone on 0.3.x is adding those bounds explicitly given the complexity of actually getting the compiler to accept them with the 0.3.x config addition -- in fact I don't think it's actually possible to get it to compile. That being said, if we wanted to be very strict about this, a 0.4.0 release is justifiable.

[steviez]

Refreshed myself here, a few notes:

• Since we are in 0.x.y, no guarantee of stability for minor
• If there is an API change, I believe the proper thing to do here is to bump the minor. It doesn't definitively state though, just this tip here when dealing with 0.x.y development

Looking at who is currently using wincode, it is:

• Anza owned repo's
• gptman (rust-disk-partition-management/gptman#144)
• coreutils (uutils/coreutils#10134)

That being said, if we wanted to be very strict about this, a 0.4.0 release is justifiable.

Given that this crate already has some adoption outside of Anza and may see more, I think we should do "the right thing" and jump to 0.4.0. We got a lot of flack (rightfully so) for our abuse of semver in the SDK, so we should probably continue to be on our best behavior moving forward 😅

[cpubot]

Updated to 0.4.0.

I also had to remove the version key in wincode's wincode-derive Cargo.toml entry in accordance with https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#multiple-locations.

If both path and version are specified, the versions between the two must be compatible. Bumping to 0.4.0 makes the version and path dependencies incompatible. I will re-add the explicit version key once this is merged and [email protected] is released.

[steviez]

Can you please update the PR title as well to reflect the update ? Otherwise, LGTM

[cpubot]

Going to hold off on merging this until #152 is merged so we can avoid minor version bump churn.

[yihau]

nit: maybe could consider this: #158 so that we don't need to remove the windoe-derive version here https://github.com/anza-xyz/wincode/pull/157/changes#diff-4d133aae7d845b7fddba013210f841831b8b322b63624ba26a0e805b8eca2737L34 (also we will need to add it back later)

for breaking api version bump, in current situation, we will need to

A:

1. have a PR to bump wincode-derive to next version and remove version field in wincode
2. release wincode-derive
3. have a PR to add version back to wincode, and here, I guess we must use the latest version

if we do patch, it will look like:

B:

1. have a PR to bump wincode-derive to next version. no changes to wincode are required
2. release wincode-derive
3. have a PR to adapt wincode to use the new version

[cpubot]

Confirmed @yihau's patch works!

[cpubot]

Hmm, it looks like CI might be using the version rather than the patch.

[cpubot]

Okay, restoring what we had previously, but pinning the version in wincode to 0.4.0. This should still allow us to maintain the adjacent path dependency and deploy [email protected].