Lokathor/bytemuck

syn patch bump should be bytemuck_derive minor bump

TheEdward162 opened this issue · 11 comments

TheEdward162 commented

Oof, I think this should have been a minor bump instead of just patch a053f1d - since the underlying crate should have been doing minor bumps this must too be a minor bump.

Otherwise it still breaks with check-minimal like here Smithay/drm-rs#119 🤷‍♀️ (it checks bytemuck_derive 1.1.0 because bytemuck depends on "1.1" in Cargo.toml)

Lokathor commented

As far as I recall the only change in that version is the license files. So syn must have already been mis-listed before that version.

I'm happy to put out another update if you figure it out.

If you want to try and add a CI run that does a check-minimal pass that'd also be fine, and might help in the future, but the derives change very rarely anyway so i don't know if you want to go to the extra effort (i hate CI stuff myself).

TheEdward162 commented

Here's what changed since the last time derive Cargo.toml version was touched:
https://github.com/Lokathor/bytemuck/compare/73ae1ee89e42be4f30d2d5e04f7f3e7fb89b6b97..a053f1d887eff7d4a0170a93e57cc728b143431f

Change of of syn version to "1.0.15" is in there so it couldn't have been released before - I don't think I updated the changelog so maybe that's a mistake on my part.

Lokathor commented

oh wow that's a lot more than i remember.

also, i saw in your linked PR that somehow there's trouble from the lack of a workspace in this repo? Shouldn't all your deps come from crates.io so this repo's layout shouldn't matter?

TheEdward162 commented

Yes, it's just that when I was trying to test the CI by using git versions (which is of course for development only) it couldn't find the new version of the derive because the workspace wasn't set up. It's not an issue that needs to be solved right now and I can always test locally, it just wasn't possible to make the CI fetch the new version from git.

Lokathor commented

Ah. Well I'm not specifically against a cargo workspace but I've never ever used one, and haven't ever been hard pressed to learn about them.

TheEdward162 commented

So can this be released with a minor version bump?

Lokathor commented

So to be clear: You just want a new release of bytemuck_derive as 1.2.0?

TheEdward162 commented

bytemuck_derive as 1.2.0 and then also bytemuck as 1.12.0 which specifies bytemuck_derive = "1.2" in Cargo.toml so I can use it.

Lokathor commented

Seems simple. Should be able to do that later today

  • 👍1
Lokathor commented

So:

  • when i said "today" i meant "tomorrow when i remember"
  • I've released bytemuck_derive-1.2.0
  • I've released bytemuck-1.12.0
  • I'm keeping the issue open because if you don't want this to happen again you should send in a PR to add a --minimum-versions (or whatever flag) run to the CI script so that we can catch this sooner. So that one is on you, because (as you probably know) 99.9% of the cargo ecosystem is happy to let cargo just pick the latest version of a crate when doing a build, so we don't notice this stuff.
TheEdward162 commented

Thanks!

As for your last point, sure, when I find some motivation again I'll send the PR, should be as simple as copy-pasting the CI from drm-rs, but one never knows...