Is the dev/main branch approach the best option?

[TimJentzsch]

The repository currently uses the main (default) branch for the current release version and the dev branch for developing new features.

As a new contributor, this can be rather annoying:

• When first cloning the repository, you need to remember to switch to dev before creating your branch.
• When creating your PR, you need to remember to switch the target to dev.
• When switching back from your branch you need to remember to go to dev (this can be easy to forget due to muscle memory, at least it already happened to me that I went to main before creating a new branch).
• Some contributors might not read the contributing guidelines (even though the should...) and not know about dev.

I think this problem is made evident by two of the open PRs targeting main instead of dev.

On the other hand, the examples are an important learning resource, especially for bevy-related projects. Looking at examples that no longer work is definitely frustrating.

Is there a better approach on how to handle this?

One solution might be to have main to still be the default branch, but to contain the current development state. A release branch could take the role of the current main branch and contain the currently released version of the plugin.
The README could then link to that branch for the examples.
This approach probably still has problems regarding the discoverability of examples, but would fix most of the footguns for developers (because the default branch is the development target).

I'm curious to hear about your experiences with this branching approach and if you have any ideas on how to improve the situation!

This might also be valuable for other bevy-related repositories.

[alice-i-cecile]

Yeah, I'm not thrilled with this. However, as far as I can tell the "default branch for PRs" and "the branch shown with the bare link" are always the same :(

I'm much more comfortable forcing developers to carry this burden than end users.