A site can only stand on the tip of trunk, never on a release branch

The gap

A Toolkit site can only ever stand on the tip of trunk. During a release cycle that is usually fine, because the nightly is the upcoming release — right up until trunk branches for the next cycle. From that day, trunk is the next version's alpha, and anyone who wanted to test the release candidate finds the app can only offer them something newer than what they came to test.

This bit for real at an event: testers set out to try the RC before code freeze and could only use the nightly. It happened to be close enough that time, because the release had branched only days earlier. The rule is not on their side, though — "nightly ≈ release" holds only while trunk still is that release. For an event falling late in a cycle, after the next version has branched, the nightly is a full version ahead of the thing being tested.

Swapping core files in place with the Beta Tester plugin is the available stopgap, but inside a managed site it means something other than the app rewriting the checkout — which the app currently does not tolerate well (see #348).

The idea

Let a site stand on a release branch — 6.9, 7.1 — instead of the tip of trunk, chosen when the situation calls for it (an event in the RC window, a bug report against a specific version). A release branch keeps receiving its RC and point-release fixes, so a site standing on it stays a faithful test target for the whole window, regardless of what trunk has become.

Three properties the feature should have:

• It is the same kind of fetch the app already does. The shallow, single-ref clone is not the obstacle it appears to be: fetching one release branch at depth 1 is the identical operation the app performs for trunk today, pointed at a different ref. No deep history, no release zips.
• The price is stated before the click. An older branch means a different lockfile and a different build — minutes, not seconds, and again on the way back. Same honesty rule as #290: the cost is inherent to the question, so the button says it rather than hiding the route.
• It coexists with the ticket model. Ticket branches (#108) are cut from what the site stands on. A ticket started against a release branch is a legitimate thing — that is what testing an RC produces — and switching the site's base must park and preserve ticket work exactly as trunk updates do.

Tags (7.1-RC4) are the finer-grained version of the same idea and use the same plumbing; branches come first because a branch keeps tracking its release while a tag freezes one moment of it.

Deliberately not proposed

Replacing trunk as the default. The nightly stays the right answer for contribution work; standing on a release branch is a deliberate, priced choice for testing windows.

Related

• #290 — standing on a ref other than trunk's tip; this is the same capability with a release branch instead of a pull request
• #226 — the recorded-base work; not required here (nothing is merged), but the ref-fetch plumbing is shared

Start with the existing shallow, single-ref trunk-fetch flow and the ref-switching work described in #290, then review ticket-branch handling from #108 and the recorded-base context in #226. Done means a site can select a release branch, see the build cost before switching, and preserve ticket work when its base changes.