Update branch and release policy

[Mirko-von-Leipzig]

Summary

This PR changes our branch policy, and updates the dev documentation to reflect this as well as the release flow.

Its best to read the docs changes, but in summary:

• I am scrapping main
• It is replaced by a dedicated vX.Y release branch
• next remains the default dev branch
• Release branches never merge back or from next again

I've also added some rulesets to enforce admin/maintainer only rights to version branching and releasing.

I have already created v0.15 from current main. Once this PR is merged, I will delete main and back-propagate the workflow changes to v0.15. And then remove the existing legacy branch protections (which don't use rulesets).

Changelog

changelog = "none"
reason    = "Internal change only."

[igamigo]

Looks good! I've been wondering where we had landed on the release branch discussion - at some point it seemed that it was going to become the new convention but eventually it looked like it was dropped. For what it's worth, I'd be in favor (and would like to change this in the client) but it's not a strong opinion: the current workflow is not usually problematic for us and IMO the main advantage of this policy is that everything is a bit clearer and easier to navigate.
Perhaps the one comment I'd make is that some repos seem to use release/vX.Y for release branches and it'd be nice to make all repos as consistent as possible, but it's very much not a big problem.

[igamigo]

Would it be valuable to check whether the tagged commit is on a correctly protected vX.Y branch to avoid arbitrary branches being used? And/or that the branch matches the tag name.

[Mirko-von-Leipzig]

imo no - I don't actually care what branch is used. Such release tags are already restricted to a subset of admins. And sometimes you need to force a release from random places.

We could make the ruleset enforce that one needs approval from at least two admins instead of just the one. But again, I don't really care where the release is from. If it was a mistake, we yank the crates/release and bump the version again in the correct place.

[bobbinth]

Haven't looked at the actual code yet - but agree with the PR description. I think the protocol repo is headed in a similar direction. cc @mmagician

The only thing we need to clarify is to make sure the documentation site building process is updated to account for this. cc @BrianSeong99 and @Keinberger

Perhaps the one comment I'd make is that some repos seem to use release/vX.Y for release branches and it'd be nice to make all repos as consistent as possible, but it's very much not a big problem.

I agree with this too. That's the convention we are using in the protocol repo, and I think we can propagate it to other repos too.

[SantiagoPittella]

In PRs like this one #2371 we don 't really care about the order of PRs by different base branches

[Mirko-von-Leipzig]

I'm not quite following; I agree with your statement - in general we don't care at all anymore because they'll never merge.

Do you want me to add a bullet point to that effect?

[Mirko-von-Leipzig]

Haven't looked at the actual code yet - but agree with the PR description. I think the protocol repo is headed in a similar direction. cc @mmagician

The only thing we need to clarify is to make sure the documentation site building process is updated to account for this. cc @BrianSeong99 and @Keinberger

I've mentioned this before, but documentation should be using tags or commits and never branches as a target. Similarly, docs should manage a manifest where they manually update the target themselves to a specific tag/commit per repo -- preferably whichever version is on testnet & devnet. This isn't automatable from the repo side because none of these repos manage what is deployed.

Perhaps the one comment I'd make is that some repos seem to use release/vX.Y for release branches and it'd be nice to make all repos as consistent as possible, but it's very much not a big problem.

I agree with this too. That's the convention we are using in the protocol repo, and I think we can propagate it to other repos too.

Bleg why use more words for the same thing, don't really see what release/ adds :D Protocol seems to make a branch for every.. release? Instead of a single one per major version.

[bobbinth]

don't really see what release/ adds

It's a bit more clarity and ability to apply the same rules to all "release" branches consistently.

[Mirko-von-Leipzig]

don't really see what release/ adds

It's a bit more clarity and ability to apply the same rules to all "release" branches consistently.

Personally I find it confusing. A release is a single thing i.e. v0.15.0, not a branch for a specific major version e.g. v0.15. The name being 90% release/ and 10% the thing we actually care also bothers me.

The rules can also be applied just fine to v*, though admittedly it does get in the way of anyone named v* naming their branches <name>/.

But this is fairly heavy bikeshedding; I'll concede to whatever :)

[bobbinth]

Personally I find it confusing. A release is a single thing i.e. v0.15.0, not a branch for a specific major version e.g. v0.15. The name being 90% release/ and 10% the thing we actually care also bothers me.

Yeah, I think one branch per minor release is fine - I'd just prepend it with release/ (i.e., release/v0.15) not to discriminate against usernames that start with v or something similar.