Open cxreiff opened 1 month ago
I'd prefer to keep it simple when possible (and avoid getting into the release engineering game). Try to avoid chasing unreleased features too hard like this unless there's a great need to do so. The problem with having multiple release branches is that it becomes cumbersome to track which one is accurate and keep them up to date, and backport fixes, and ....
Instead I'd generally leave a PR that depends on an upstream fix open until it can be merged after release.
This is not a hard and fast rule, but it's one that leads to less time spent.
With you on that. Leaving it up to you whether to keep this issue open and I'll revisit come official release time.
Keep it open - it's worth knowing that this will come up in the next release.
Bevy merged a PR adding a
repeat
boolean to the KeyboardInput struct, corresponding to an equivalent concept inwinit
. When forwarding crossterm events we should correctly set this flag when reported by the terminal or we can reasonably identify a repeat event as part of our emulation strategy.Holding off on a PR until events are refactored, just opening this to keep this bevy input change on the radar as I'm not sure if it will be mentioned in 0.15 migration materials.
(Side conversation: how should changes like this and the event refactor, that depend on unreleased changes in bevy, be handled with release-plz? Should a separate 0.15 branch be kept?)