Proposal to enable branch protection on 0.11 + default branch changes

[aleokdev]

I've been thinking about it for a while, and I believe it'd be a good idea to keep previous major versions (e.g. 0.10) on their own branches when we update, since that way we could insert patches for major bugs without forcing users to upgrade. Of course, the crate is <1.0 so it doesn't make much sense right now, but it will once we reach 1.0, or plan a LTS release.
My idea is to rename the current master branch to 0.10, and update the default branch to 0.11 once it is released. That way, we'll clarify what version the default branch refers to and which changes go into it.

(P.S. It'd be a good idea to enable branch protection on other major version branches like 0.11, as well.)

[bjorn]

I think it's a good idea to keep around a branch for previous releases in case we still want to do a patch release for them, but I don't think it's a good idea to keep changing the default branch, mainly because this makes it harder to easily stay up-to-date by just pulling the latest changes (since now it will sometimes require switching branches, which also breaks the "fetch upstream" feature on GitHub).

Personally I would propose to also change the naming for the next breaking branch to not be version-specific. Maybe the master branch could be renamed to current and the 0.11 branch could be renamed to next? Once we want to release 0.11:

• Branch 0.10 off from current
• Merge next into current
• Tag v0.11.0 on current

And then next is the branch for 0.12 or 1.0, whichever comes first.