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

v0.23.0 release #1704

Closed
6 tasks done
francesca64 opened this issue Sep 14, 2020 · 14 comments
Closed
6 tasks done

v0.23.0 release #1704

francesca64 opened this issue Sep 14, 2020 · 14 comments
Labels
C - needs discussion Direction must be ironed out S - meta Project governance

Comments

@francesca64
Copy link
Member

francesca64 commented Sep 14, 2020

The "Unreleased" section of the CHANGELOG is getting impressively long... it seems like this has led to inconvenience for some people.

Does anybody have any objections to cutting a new release soon? These are the only blockers I currently know about:

@cart is there anything else you'd need for switching to upstream other than a new release?

@francesca64 francesca64 added the S - meta Project governance label Sep 14, 2020
@cart
Copy link

cart commented Sep 14, 2020

Theres nothing else I need. I'm very happy to see that parking_lot just got bumped, I was just about to ask for that 😄

@francesca64 francesca64 added the C - needs discussion Direction must be ironed out label Sep 14, 2020
@JMS55
Copy link

JMS55 commented Sep 14, 2020

Please also wait for #1653, it is a huge improvement to Wayland, and seems to be pretty much done.

I am looking forward to the next release soon though!

@kchibisov
Copy link
Member

yeah, we need #1653 downstream, since it fixes a lot of things, it's done, but waiting for review at the moment. I'll work on #1670 since it's a breaking change and also a very important API change for Wayland to make fullscreen startup possible.

@MichaelHills
Copy link
Contributor

I think there might be an iOS crash when you swipe-up the control centre (or is it swipe down from top right now? I'm on iphone 6 still). I might have a crack at fixing it tonight or before the release is cut but I would regard this more as me trying to sneak some more fixes in before the deadline rather than a blocker.

@cart
Copy link

cart commented Sep 16, 2020

I'll pile on to the "lets wait for #1653" train. It results in a nice consolidation of quote dependencies.

@alvinhochun
Copy link
Contributor

Should something be done about the stdweb backend (#1662) in this release, or should it wait for the next release or later?

@francesca64
Copy link
Member Author

francesca64 commented Sep 17, 2020

@alvinhochun deprecating it now and waiting to remove it until 0.24.0 would be the conservative approach. However, if you believe that fairly few people are currently using the stdweb backend and/or if migrating is easy, then I think we should just be aggressive and remove it now.

Also, it looks like you've been doing a lot of great work on winit's web support. Would you like to be made a rust-windowing Member?

@alvinhochun
Copy link
Contributor

deprecating it now and waiting to remove it until 0.24.0 would be the conservative approach. However, if you believe that fairly few people are currently using the stdweb backend and/or if migrating is easy, then I think we should just be aggressive and remove it now.

I replied to this in #1662 (comment)

Also, it looks like you've been doing a lot of great work on winit's web support. Would you like to be made a rust-windowing Member?

I can't promise to help maintain the web backend. I'm still not quite familiar with the winit codebase, so I would rather not have write permission for now as long as someone is active to review and merge my PRs (this stops me from doing stupid things).

@chrisduerr
Copy link
Contributor

if you believe that fairly few people are currently using the stdweb backend and/or if migrating is easy, then I think we should just be aggressive and remove it now.

I strongly advise against just removing features without clear prior communication. That sends the wrong message for all backends if you ask me.

@alvinhochun
Copy link
Contributor

if you believe that fairly few people are currently using the stdweb backend and/or if migrating is easy, then I think we should just be aggressive and remove it now.

I strongly advise against just removing features without clear prior communication. That sends the wrong message for all backends if you ask me.

Agreed. How should we communicate the intention of removing the stdweb backend? Is simply marking it deprecated for one or two breaking releases enough?

@chrisduerr
Copy link
Contributor

Agreed. How should we communicate the intention of removing the stdweb backend? Is simply marking it deprecated for one or two breaking releases enough?

Yes, marking it deprecated should be sufficient. The timespan for which it is marked deprecated is probably much more important than the number of breaking releases, since there's very little reason to just update to every second release of winit or something similar.

@ryanisaacg
Copy link
Contributor

I'm on chris's side here, I think we should throw a warning at any user of stdweb in this release, note this prominently in the changelog, and possibly reach out to any downstream projects that are still depending on it. In a future release, we can actually make the removal.

@kchibisov
Copy link
Member

I've opened #1729 since every PR mentioned here was merged. If anyone has any concerns about releasing let me know.

@kchibisov
Copy link
Member

Release was cut.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C - needs discussion Direction must be ironed out S - meta Project governance
Development

No branches or pull requests

8 participants