0.29.0 Release planning

[kchibisov]

Essential patches

The next winit release will have some massive reworks of internals and API, and such reworks are pretty huge. To make it less painful this issue to help organize the work on the following massive PRs to simplify the life for everyone else.

The main thing of the next release will be #2662 (keyboard input v2).

Given that, any non trivial changes and changes to public API are blocked until it'll be merged.

After keyboard input v2 the backends will be unblocked from further development, except Wayland and maybe X11 ones, for them see:

• - Update wayland-rs to 0.30.0 #2676 ; Wayland backend rewrite for wayland-rs 0.30, which is essential for forward compatibility with the protocol.
• - internal: Add libxcb and replace some Xlib functions #2614 ; Rewrite of X11 backend to be more maintainable and safer. This one is optional, but we'll see how it goes

Any updates to them will be discarded entirely if they come in the wrong time. This statement will hold for Wayland for sure, and maybe in more relaxed form for X11.

Actual release

Given that the amount of non-trivial changes to the next release, we might consider doing RC process, because both Wayland/X11 backends could be not in really usable state and something from them could be missing. We might also want the ability to breaking change new keyboard.

Side notes

The state of readiness for the next release will be tracked via milestones and separate issues. This issue is solely a notice for other maintainers/contributors about temporary shifted focus and API freeze.

[kchibisov]

The Wayland patch got merged, so it's now unfrozen for hot fixes.

[kchibisov]

As a soft deadline I'd say 0.29 will be in the end of July, beginning of August (2023).

Given that's all open source development, things will likely change a bunch of times.

[kchibisov]

The freeze is now removed. The release is still being planned on Augest(maybe July) so we can polish the bugs/internal changes.

[maroider]

I think going for a release candidate could be useful, but I guess we'll have a better idea closer to a potential release.

[kchibisov]

Yeah, we probably have an rc series for the 0.29 however I'll do it closer to release anyway(end of June). I know that neovide is using the keyboard input actively so they should give us a good information wrt the bugs present.

[kchibisov]

Given that multiple big projects(bevy/neovide) are using winit from master and I personally want to use winit in alacritty development as well. There will be betas for the upcoming release.

Betas will represent snapshots from winit development branch and flow into v0.29.0 release. I'll start betas within a week or two.

[kchibisov]

beta.0 is done.

[kchibisov]

The release is getting delayed until the end of the August, because there're still some features needed to be implemented and we'd need a beta2 test drive.

[kchibisov]

winit 0.29.1-beta is done. The naming was picked to work around cargo limitations and shouldn't result in any breakages.

[madsmtm]

I've been burned by cargo and beta releases before, so as a todo before final release: Depend on a non-beta release of android-activity

[kchibisov]

Yeah, you must not depend on beta releases for real releases, that's expected. I just got surprised that it thinks that all betas are compatible with each other.

[kchibisov]

The release will likely be delayed until some internal wayland stuff is sorted wrt to queue dispatching, it's not like a big issue now, but it's not directly depends on me either.

The end goal of all of that that crates like https://github.com/smithay/smithay-clipboard could do proper waiting for the events without polling each 50ms which is ridiculous.

It's also take time for me to propagate some changes through out the https://github.com/smithay/client-toolkit and https://github.com/polyMeilex/sctk-adwaita to account for stuff like that.

[kchibisov]

I'll unlock the issue to let other parties to nominate stuff for the next release which is not a part of the milestone or speak up if they need a release sooner than it might be in the end.

[madsmtm]

I'd like to nominate #3075, or at least in some way figuring out how our support strategy is going to be for future versions of raw-window-handle (which is an unstable dependency that we expose publicly).

[kchibisov]

Yeah, that one sounds fine.

[daxpedda]

I added #3082 as well, which can be merged anytime, but I'm gonna let it simmer for a while.
Just added it to not forget to merge it before release.

[kchibisov]

The android crates will take a bit of time to release, but shouldn't be more than two weeks.

rust-mobile/ndk#413 (comment)

[MarijnS95]

Is raw-window-handle 0.6 going to be part of 0.29? If so, part of that task is finalizing the migration (which is already approved bar a SAFETY comment discussion) at rust-mobile/ndk#434.

[kchibisov]

Yes, it'll be.

[kchibisov]

@MarijnS95 could we have android stuff released soon-ish? I've done with all other deps, so only android is left on the plate.

[MarijnS95]

@kchibisov sure thing, I've been assessing where to go with the new raw-window-handle 0.6 bindings but it looks like it's all been resolved.

[kchibisov]

yeah, we basically need a few bugfixes, but getting crates we depend on released is the major priority, since it's out of my control.

[MarijnS95]

@kchibisov what kind of bugfixes? Note that the ndk crate also provides a raw-window-handle implementation directly so that users don't have to rely on winit for that.

(Especially useful when having a Java/Kotlin app and only mapping a View into Rust and a graphics API, instead of having Rust/winit control the whole window)

[kchibisov]

they are on the milestone, you can look at things I've marked. I'd at least try to address the one on macOS.

[MarijnS95]

@kchibisov all done now: #3145

[dhardy]

I recommend merging/rejecting #3143 before release to minimise churn of keyboard API.

[kchibisov]

I'll be doing a release tomorrow if nothing new will appear.

[MarijnS95]

Nice! I've been rushing the ndk release (and obviously already found more issues that could have benefited from a breaking release) and was looking forward to this.

[kchibisov]

Release done.