-
Notifications
You must be signed in to change notification settings - Fork 50
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
Alleviate the need for ecosystem-wide upgrading to 0.4.1 #74
Alleviate the need for ecosystem-wide upgrading to 0.4.1 #74
Conversation
Uses the semver trick, see https://github.com/dtolnay/semver-trick The idea is that this will allow crates whose purpose is to provide an `HasRawWindowHandle` implementation to upgrade first (e.g. `winit`, `sdl2`, `glfw`, `fltk`, ...). When a sufficient amount of "provider" crates have upgraded, "consumer" crates (e.g. `gfx`, `wgpu`, `rfd`, ...) can safely start upgrading without breaking for downstream users.
It would be helpful if someone could create a |
I hope this was what you wanted :) |
@@ -16,6 +16,7 @@ appveyor = { repository = "rust-windowing/raw-window-handle" } | |||
|
|||
[dependencies] | |||
libc = {version="0.2", features=[]} | |||
new = { version = "0.4.1", package = "raw-window-handle" } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if this, or by using extern crate raw_window_handle as new;
is the most robust way to rename a crate?
If you agree that this is desirable, I'm thinking the way forward is to:
|
This all seems like a good idea, but i've never done the semver trick thing before. First, I should just merge this, right? |
Well, I haven't done it before either, but I'm fairly certain it will work, so yes, merge this and make a release It should be noted that adding blanket implementations of |
Okay, i'll merge this now then. |
* Update raw-window-handle to `0.4.2` See: - rust-windowing/raw-window-handle#72 - rust-windowing/raw-window-handle#73 - rust-windowing/raw-window-handle#74 * Clean up raw_window_handle functions a bit
`raw-window-handle 0.3.4` was pushed as a "semver-trick-like" patch release, implementing the `0.3` trait for the `0.4` crate release [74]. This allows `ash-window` as a window-handle "consumer" crate to accept both `0.3` and `0.4` handles from consumer crates simultaneously. To ensure this patch release is available even when users omit regular `cargo update` or build with `-Z minimal-versions`, set the minimal patch version in `Cargo.toml` to it. [74]: rust-windowing/raw-window-handle#74
#553) `raw-window-handle 0.3.4` was pushed as a "semver-trick-like" patch release, implementing the `0.3` trait for the `0.4` crate release [74]. This allows `ash-window` as a window-handle "consumer" crate to accept both `0.3` and `0.4` handles from consumer crates simultaneously. To ensure this patch release is available even when users omit regular `cargo update` or build with `-Z minimal-versions`, set the minimal patch version in `Cargo.toml` to it. [74]: rust-windowing/raw-window-handle#74
This PR is opened againstmaster
, but in reality it should be merged into 5207e99.Using the semver trick, we can make upgrading from
0.3
to0.4.1
much less painful!We simply add a
v0.3
HasRawWindowHandle
impl for av0.4.1
HasRawWindowHandle
, and releasev0.3.4
.The idea is that this will allow crates whose purpose is to provide an
HasRawWindowHandle
implementation to upgrade first (e.g.winit
,sdl2
,glfw
,fltk
, ...). When a sufficient amount of "provider" crates have upgraded, "consumer" crates (e.g.gfx
,wgpu
,rfd
, ...) can safely start upgrading while minimizing breakage for downstream users.