Standing on an exact released version, not just a release branch

The gap

#349 lets a site stand on a release branch, which tracks a release as it keeps receiving fixes. That is the right default for an event happening inside a release window. It is not what someone reproducing a bug needs: a report filed against 7.1 RC4 has to be reproduced against 7.1 RC4, and the 7.1 branch stopped being RC4 the moment the next fix landed on it.

The plumbing is the same single-ref, depth-one fetch as everywhere else in this work. What is not the same is the model, and that is why this is filed apart from #349 rather than as a line inside it.

The part that needs deciding

A branch is a place you can stand and build on: work committed there has somewhere to go. A tag is a fixed point, and standing on one leaves the checkout detached — no branch under the contributor's feet. That collides with the ticket model (#108), where work lives on a branch cut from whatever the site stands on:

• Can a contributor start ticket work while standing on a tag at all, or is a tagged site read-only by nature — a thing you look at, not a thing you write on?
• If they can, what is the branch cut from, and what is the diff measured against — the tag, or the trunk their eventual patch has to apply to? Those are different answers and only one of them produces a patch anyone can use.
• What happens to that work when the site later moves back to trunk or forward to another version?

The honest possibility worth weighing: reproduction and contribution may simply be different modes, and a tagged site being explicitly read-only — "you are looking at 7.1 RC4; to fix something, come back to trunk" — may be a better answer than a half-supported writable one. Deciding that is the substance of this issue; the fetch is the easy part.

Why it matters beyond one bug report

Reproducing against an exact released version is the first half of triage, and triage is what most newcomers can genuinely do on day one. An app that can only ever show them the nightly can host the fixing but not the confirming.

Related

• #349 — release branches; same plumbing, different question, decided first
• #350 — the contract
• #108 — the branch model this has to answer to
• #290 — the other foreign-ref consumer

Start by reading issues #349, #350, #108, and #290 to understand the release-branch plumbing, contract, branch model, and other foreign-ref consumer. Decide whether an exact tagged version is read-only or supports contribution, including branch and diff behavior. Done means the supported behavior and transition between versions are explicitly settled.