Introduce proper trunk/backport workflow

[rami3l]

For now every rustup release is directly merged onto trunk and thus we might want to block patch releases from happening once a major/breaking change has landed (or vice versa). This is not very practical.

To keep and even further increase the bandwidth and momentum, an important change we would need to make to the current workflow would be to allow people from both inside and outside of the project to contribute whenever they want, and for the changes to land in the right release in a more flexible timeframe, so that we can introduce major changes even when we are waiting for patch releases. Thus the desire for a backport branch that collects all the bugfixes in this minor cycle, with proper CI and even CD (when the new release process is ready), from which we will force-push our stables.

Surely this needs more bandwidth, so it will probably not happen immediately, but I can see that this might be an important step in ensuring the project's long term health.

[ChrisDenton]

We could maybe ask if anyone from infra would help set up a stable branch (maybe a beta branch too?). Even if we can't make much use of it to start with, having something to build on would be useful.

[rami3l]

@ChrisDenton The current stable branch is a placeholder for "what we want to deploy as the next release" but the semantics is too ambiguous it seems to me: we reuse it for every beta and every stable, and there's no guarantee that at a given point in time what that would be. I'm thinking about branches like X.YY with proper CI so that we can at least have something to track.

[djc]

For other projects I usually have branches like 1.29.x once main has incompatible changes and a maintenance release needs to be made. But IMO there is not much point in making these branches proactively, since you can always make them when needed?

[ChrisDenton]

I thought the hard part was not creating the branches themselves (that's of course easy) but that all our infrastructure is based on the current setup (CI scripts, etc).

[rami3l]

I thought the hard part was not creating the branches themselves (that's of course easy) but that all our infrastructure is based on the current setup (CI scripts, etc).

@ChrisDenton Exactly. For now a reasonable next step for us seems to be that:

• Versioned backport branches get full CI both during backport PRs and upon push.

  • Unlike trunk where we also have the more scheduled "heavy CI runs", on versioned backport branches they are disabled.
  • Nonetheless, we should have a mechanism to trigger heavy CI on demand on those branches without having to use the config on other branches.

• Change the release process so that the stable branch only serves as a staging area for releases. This will notably include force-pushing from any writer to this repo.