Release cadence?

[MeoMix]

Hey there!

Just curious what the release cadence is like for this repo. There's a change that was merged into main back in October that I'm very excited to see ship as it'll ensure my app works on Android with Bevy's next release - likely to occur in another three months or so.

Is it reasonable to assume the next patch version will ship within the next three months?

Thanks!

[MarijnS95]

Breaking releases likely occur at the same pace as winit, so that we don't end up in a situation where the majority of the users cannot use the update until winit upgrades.

Patch releases can be published on request, though we have already accumulated some breaking changes on the main branch, and would have to backport the rest to a non-breaking branch.

[MeoMix]

Understood! Thank you for your quick and clear response.

For clarity, #142 moved the full ndk dependency to dev-dependencies and made ndk with default-features = false the default dependency.

This change is required to unblock Bevy from updating its winit dependency to 0.29, bevyengine/bevy#10702 (comment) which will resolve an issue preventing Bevy WASM applications from running on Android devices, bevyengine/bevy#7038 (comment)

It seems reasonable to view #142 as breaking. Consumers may have become dependent on default features being enabled.

However, it seems like a fairly minor concern when contrasted with the benefit. It would be unfortunate for Bevy to wait an additional 3-4 months to sync with winit 0.29 due to a dependency syncing with 0.29 having shipped its update while incompatible with Bevy.

All said, I'm comfortable with any approach taken as we're in a marathon not a sprint and I don't want to cause undue headache. If you find these concerns compelling then please consider them. Otherwise, let me know, and I'll relay the information.

Cheers!

[MarijnS95]

I'm aware, and since you mentioned Bevy I figured you were looking for that PR. I'd also like to get that out in a release as our graphics backend is not ready to use raw-window-handle 0.6 yet, and we're just using [patch.crates-io] now. Unfortunately, as you also found out, such a change is breaking. We may have gotten away with it early during the release of android-activity (i.e. yanking the initial release) but now it's too late.

It would be a lot less concerning if winit can do a breaking upgrade of android-activity in a patch release, but its types are used publicly.

@rib any idea/suggestion here?

---

And for the next ndk release, I won't enable any raw-window-handle dependency by default at all. Showing people that it's supported, and pushing for the latest version, does not outweigh the hassle it has caused thus far (i.e. forgetting default-features = false in every public dependency: rust-windowing/winit#3210).

[rib]

I was just rolling a 0.5.1 release including the change to not depend on the ndk crate default features after @Vrixyz had pinged my about this a few days ago.

Patch releases can be published on request, though we have already accumulated some breaking changes on the main branch, and would have to backport the rest to a non-breaking branch.

erm, we don't have any breaking changes since 0.5 as far as I see?

renaming the threads seems fine to me (technically someone could have become dependent on the names but seems relatively unlikely currently)

I don't consider the avoidance on depending on ndk default features a breaking change that's not affecting our public API. If downstream depends on any default features in the ndk crate then they should anyway depend on the ndk crate themselves (with or without default features) - we don't re-export the ndk crate currently.

One thing I had wanted to double check though was why did the ndk crate get added as a dev-dependency in #142 (though that also wouldn't be a semver issue either)

[MarijnS95]

we don't re-export the ndk crate currently.

https://docs.rs/android-activity/latest/android_activity/struct.AndroidApp.html#method.native_window

One thing I had wanted to double check though was why did the ndk crate get added as a dev-dependency in #142 (though that also wouldn't be a semver issue either)

Good catch - I thought there were examples but they're separate apps and not part of the main library package - that should go.

[rib]

we don't re-export the ndk crate currently.

https://docs.rs/android-activity/latest/android_activity/struct.AndroidApp.html#method.native_window

Urgh, damn! :/ and that type specifically is affected by the rwh features :/

[extrawurst]

Can’t wait for the release, will hopefully unleash such a ripple effect of winit update finally unblocked to merge into bevy 🫶

[rib]

Okey, #149 has just been merged and I've published a release to crates.io and Github.

Hope that unblocks you @extrawurst and @MeoMix.

Thanks for the review @MarijnS95

[MeoMix]

Thanks all. Appreciate you. Happy holidays.