bump minor version #468
bump minor version #468
Conversation
|
merged master |
|
closed pending some issues in discussion here. Will reopen when that's resolved. |
|
the offending commit was reverted |
|
I'm curious what the reason for going with 0.13.0 rather than 0.12.1 is. I'm not saying I'm necessarily opposed to it; I just want to make sure there's a rationale. |
|
@francesca64 good question. I'm mostly just trying to follow semver. I know this is pre-1.0, but I still think the minor = features, patch = bugfixes semantics have value. I'd be happy to change it to a patch if that's preferred, though. |
|
My first time trying to write a response, I kept trying to use the term "breaking change", but then I started to reflect on what constitutes a breaking change. For instance, this release contains a bunch of platform parity fixes to the values returned by window position/geometry functions. Someone who only uses winit on one platform wouldn't have had any reason to see the old behavior as a bug, and the behavior of their application could be broken in ways that are more subtly dangerous than breaking API changes. It's possible that a minor bump would make people more likely to check the changelog, though that could be wishful thinking on my part. On that note, the necessity of checking the changelog is perhaps the least bikesheddy criteria we can come up with for this: a minor release could indicate "we're aware of bad/surprising things that could happen to you if you don't check the changelog" whereas patch releases would be "it's still a good idea to check the changelog, but we're reasonably sure you'll be fine if you don't". Either way, I definitely want to get #472 resolved before this. |
I guess it seems to me like one of the main reasons to use winit is to get multi-platform support, so I'm not sure I entirely agree with that. I think I would characterize those issues as consumers relying on buggy behavior. I also think since winit is still pre-1.0.0, changes like that are especially acceptable. But I'd be happy to change it to whatever version you think is appropriate. |
|
merged master, which includes the fix for #472 |
|
@sodiumjoe not all developers have the luxury of being able to test things on multiple platforms, and our documentation doesn't always do a good job informing you of what's supposed to happen. All the shenanigans with Anyway, I don't actually have any objections. What's your stance on whether or not #476 should be included? It just needs a macOS review and it should be good to go, though I'd understand if you don't want a breaking API change tacked onto this release. |
|
Makes sense to me to include it. |
|
will reopen once #476 is merged |
CHANGELOG.md
Outdated
| @@ -1,5 +1,7 @@ | |||
| # Unreleased | |||
|
|
|||
| # Version 0.13.0 (2018-04-17) | |||
|
|
|||
| - Implement `WindowBuilder::with_maximized`, `Window::set_fullscreen`, `Window::set_maximized` and `Window::set_decorations` for MacOS. | |||
| - Implement `WindowBuilder::with_maximized`, `Window::set_fullscreen`, `Window::set_maximized` and `Window::set_decorations` for Windows. | |||
| - On Windows, `WindowBuilder::with_dimensions` no longer changing monitor display resolution. | |||
There was a problem hiding this comment.
When you update the date, could you please correct this to WindowBuilder::with_fullscreen?
No description provided.