Since Bevy adopted a train release schedule, it makes less sense to closely track Bevy's main branch. This PR will make the master branch depend on Bevy 0.10. I already pushed a bevy-main branch that tracks Bevy as we always did. I also adapted the GitHub Actions workflows to also work with bevy-main.
The new PR policy will be that changes should be targeted preferably on the master branch, while bevy_main is for fixing breaking changes and for using Bevy features not yet supported on release.
TODO
[x] Add a Contributing.md guide to help developers choose the right target branch. This will be done in a separate PR.
[ ] Develop and document a merge strategy of bevy-main into master, needed each time a new Bevy version releases.
Since Bevy adopted a train release schedule, it makes less sense to closely track Bevy's
mainbranch. This PR will make themasterbranch depend on Bevy 0.10. I already pushed abevy-mainbranch that tracks Bevy as we always did. I also adapted the GitHub Actions workflows to also work withbevy-main.The new PR policy will be that changes should be targeted preferably on the
masterbranch, whilebevy_mainis for fixing breaking changes and for using Bevy features not yet supported on release.TODO
Contributing.mdguide to help developers choose the right target branch. This will be done in a separate PR.bevy-mainintomaster, needed each time a new Bevy version releases.