Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate from winapi to windows-sys. #32

Merged
merged 1 commit into from
Jul 2, 2022

Conversation

sunfishcode
Copy link
Contributor

This PR migrates terminal_size from winapi to windows-sys.

Windows-sys is actively maintained, by Microsoft, and has recently
started to be adopted in the ecosystem; mio, parking_lot, wasmtime,
and others have moved to windows-sys.

Migrating terminal_size to windows-sys will help me remove one more of
Wasmtime's transitive dependencies on winapi.

This PR migrates terminal_size from winapi to windows-sys.

Windows-sys is actively maintained, by Microsoft, and has recently
started to be adopted in the ecosystem; mio, parking_lot, wasmtime,
and others have moved to windows-sys.

Migrating terminal_size to windows-sys will help me remove one more of
Wasmtime's transitive dependencies on winapi.
@eminence
Copy link
Owner

eminence commented Jul 1, 2022

Thanks. It's neat how small this patch is.

This is obviously a fully semver-compatible change, so I'm inclined to release this as patch version bump (0.1.18). Can you think of any reason why that would be a problem?

@sunfishcode
Copy link
Contributor Author

I think a patch version bump will work. This isn't the only crate to do so; for example, mio updated from winapi in a patch bump bewteen 0.8.2 and 0.8.3.

@eminence
Copy link
Owner

eminence commented Jul 2, 2022

Ah, it seems that this change bumps the MSRV from 1.31 to 1.35. Normally this would be fine and I would just release a new 0.2 version of terminal_size, but I suppose this semver-incompatible release makes it harder for you to update wasmtime (since it you won't be able to just update your wasmtime lock files)

@eminence
Copy link
Owner

eminence commented Jul 2, 2022

I took a look at some of the most popular crates that depend on terminal-size, and I don't think any of them would be impacted by a MSRV bump in a patch revision

(click to see boring details)
  • Clap: has MSRV of 1.56
  • textwrap: MSRV of 1.56
  • console: no documented policy, but doesn't build with 1.35
  • miette: no documented policy, but doesn't build with 1.35
  • starship: no documented policy, but doesn't build with 1.35 (and is primarily a CLI)
  • progress: builds with 1.35, but has no policy, and is probably not actively maintained
  • du-dust: no documented policy, but doesn't build with 1.35 (and is primarily a CLI)
  • lsd: no documented policy, doesn't build with 1.35 (and is primarily a CLI)
  • mdcat: no documented policy, doesn't build with 1.35 (and is primarily a CLI)
  • nu-commands: unknown
  • tauri-cli: no documented policy, doesn't build with 1.35
  • vt100: no documented policy, doesn't build with 1.35
  • dutree: no documented policy, doesn't build with 1.35 (and is primarily a CLI)
  • xcompress: no documented policy, but doesn't build with 1.35
  • arctk: no documented policy, but doesn't build with 1.35

(A random grumble to myself: I keep feeling that my attempts at maintaining a MSRV policy ends up being not worth the hassle, given how little of the ecosystem seems to care about MSRVs)

@sunfishcode
Copy link
Contributor Author

Ah, it seems that this change bumps the MSRV from 1.31 to 1.35.

I believe it bumps the MSRV to 1.48. I'm unable to build this with windows-sys on 1.47 but I am on 1.48. I've now updated the crate documentation to reflect that.

Normally this would be fine and I would just release a new 0.2 version of terminal_size, but I suppose this semver-incompatible release makes it harder for you to update wasmtime (since it you won't be able to just update your wasmtime lock files)

A semver bump would be less convenient for wasmtime, but not the worst. It'll be a while before all the transitive dependencies migrate to window-sys in any case.

I took a look at some of the most popular crates that depend on terminal-size, and I don't think any of them would be impacted by a MSRV bump in a patch revision
(click to see boring details)

(A random grumble to myself: I keep feeling that my attempts at maintaining a MSRV policy ends up being not worth the hassle, given how little of the ecosystem seems to care about MSRVs)

1.48 is the version in Debian stable and I use it as an MSRV in several crates I maintain, as I've found it's kind of a "sweet spot" that's reasonably old at this point while being not too much of a burden to maintain as an MSRV.

@eminence
Copy link
Owner

eminence commented Jul 2, 2022

I believe it bumps the MSRV to 1.48.

Hmm, I know your other rustix PR will bump all the way to 1.48, but I think this PR only bumps to 1.35. I just checked again and I can run cargo test on 4785a40 with both 1.35 and 1.47.

Ok, here's what I'm going to do: I going to drop 02d8428 from this PR (since it will conflict with #33 ), merge both PRs, and then release a v0.2 release

@eminence eminence merged commit 4ee3acb into eminence:master Jul 2, 2022
@eminence
Copy link
Owner

eminence commented Jul 2, 2022

Released on crates.io as v0.2.0

@sunfishcode sunfishcode deleted the windows-sys branch July 6, 2022 20:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants