Release cadence?
MeoMix opened this issue · 9 comments
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!
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.
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!
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).
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)
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 adev-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.
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 :/
Can’t wait for the release, will hopefully unleash such a ripple effect of winit update finally unblocked to merge into bevy 🫶
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
Thanks all. Appreciate you. Happy holidays.