RFC 0: Tracking Rust versions

[xdoardo]

Summary

Rust development operates on a train schedule. In short: development happens on the master branch. Every six weeks, the beta branch is updated to match the latest commit from the master branch. The stable branch is then updated to match the latest commit from the beta branch before its last update to master.

It seems, to me, that our intention would be that of tracking master once we have the resources to do so. My proposal is that of tracking master and one of beta and stable; initially only the one we choose between beta and stable. The current beta is two weeks old and will be stabilised on September 18th. Another important requirement is that we don't want to lag behind too much: IIRC we mentioned 1-2 versions behind at most.

The advantages of tracking beta are:

• Starting with beta gets us a bit closer to where master is now, when we want to start tracking it.
• We get stable for free, if we ever want to have it.
• It has a commit that introduces the parsing of p- specifications in the DataLayout string and specifying the default address space of a target. This commit is not in stable yet.

The advantages of tracking stable are:

• Stabler than beta: some commits that fix errors nightly builds find on master are backported to beta.

Tracking Rust versions

My proposal is:

1. We start tracking beta.
2. We start tracking master as soon as we can, potentially from the start - if not, hopefully before the time Rust 1.90 is released.
3. Once the current beta becomes stable, if we started tracking master we'd have all three branches in working fashion.
4. We can now decide whether we want the continue the development with the stability of stable or the features from beta.

If we decide to keep working on beta we can also completely disregard stable until we want to make releases ourselves.

Alternatives

• Living on the edge and developing on master only
• Trusting our future selves and developing on stable only
• ...?

[seharris]

Yeah, tracking beta initially and then master either now or in a few weeks once we have more person-time to use sounds reasonable to me.

[mbatty]

I agree with that.

[resistor]

Just to relate this to how we currently manage our LLVM branches: at any given time, we are tracking upstream, previous release, and next release (if it has already branched). I do development work on the stable branch and then cherry-pick onto the other branches.

Since it's mostly just me committing to it, cherry-picking isn't that hard to keep sorted. With 3-4 committers actively working on Rust, you may want to consider some automation for cherry-picking across branches.

[xdoardo]

you may want to consider some automation for cherry-picking across branches

It'd be great to have GitHub's CI automatically create PRs to the other branch(es) once a PR is merged on the development branch. For example, if we work on stable, once a PR to stable is merged, GitHub automatically tries to merge the code from the same PR onto beta and master, creating PRs if CI checks fail.

Of course, this would make sense only if we use PRs to manage contributions (otherwise having a PR for every commit to the dev branch would be too much) and if there's some sort of CI in place.

[xdoardo]

We now have master and beta. I'll try to keep master updated.