feat(release): prefix app tags app/v so they leave SwiftPM's namespace

[prakashrj]

Delivers backlog 999.2 / audit W-1.

The coupling

This repo is both an app and a SwiftPM package, and SwiftPM claims every tag that parses as a version. So v0.1.1+9 was simultaneously the app's release marker and package version 0.1.1. An App Store metadata bump published a package version, and adopters got a bump from a commit that never mentioned SwiftPM.

The measurement contradicted the plan

The roadmap's third option was "publish the package from a separate tag series that SwiftPM resolves — needs checking whether SwiftPM can be pointed at a non-default tag scheme". I checked, by tagging this repo and resolving against it:

tags present	.upToNextMajor(from: "0.1.0") resolved to
pkg-0.3.0, package/0.4.0, release/0.5.0, milestone/v0.2	0.1.1+9 — every prefixed tag ignored
v0.2	0.2.0 — a bare tag claimed immediately

That option does not exist. But the inverse works, and it was not in the options list at all: move the app tags out of SwiftPM's view and leave the package namespace clean.

app/v0.1.2+10   an app release; invisible to SwiftPM
0.2.0           a package release, cut deliberately

Neither remaining option was needed — the package did not have to move to its own repo, and the coupling did not have to be accepted. The two lifecycles now move independently in one repo, which the backlog note said was the thing that could not be had.

Implemented upstream

RELEASE_TAG_PREFIX in apple-shipkit#286, plus #287 fixing plumbing that #286 shipped incomplete — the value reached neither .bootstrap.env readers nor the fastlane subprocess, so ship.rb would have computed app/v0.1.2+10 and handed it to a process that still stripped v, leaving every artifact name built from the unstripped tag. Found while adopting it here, not by re-reading the diff.

Unset means v, so no other fork changes behaviour.

Verified end to end, on the real path

$ bundle exec ruby bin/compute-release-tag.rb
app/v0.1.1+10

$ RELEASE_TAG_PREFIX=v bundle exec ruby bin/compute-release-tag.rb
v0.1.1+10

.bootstrap.env → Config → ENV → Version.tag_prefix → tag. Env precedence and default-equivalence both proven, not inferred.

Compatibility

v0.1.0+6 and v0.1.1+9 stay published and remain the current package versions. Every reader strips the configured prefix and then falls back to a bare v, so pre-change tags still parse — ci/bump-asc-version.rb may still be handed either.

ci/check-release-commit.sh now says which kind of tag a ship is about to push. Its W-1 "this is also a package version" note fires only when the tag really is SwiftPM-visible:

  note This tag is an APP release only (prefix 'app/v').
       SwiftPM ignores tags that do not parse as a version, so this ship
       publishes NO package version — adopters stay where they are until
       somebody cuts a bare X.Y.Z tag on purpose.

Both branches exercised.

A package release now requires cutting a bare X.Y.Z tag on purpose. That is the point, and it is documented in AGENTS.md and .bootstrap.env.example.

Local: tag_prefix_test.rb 23/23, check-shell.sh clean, check-patch-registry.sh passes.