Migrate to the next-version Soldeer release lifecycle (bump [package].version)

[thedavidmeister]

The shared rainix-autopublish reusable switched from the old auto-bump Soldeer model to a next-version release lifecycle (rainlanguage/rainix#264, merged). Your .github/workflows/package-release.yaml pins the reusable at @main, so the new behaviour is already live.

What changed

[package].version in foundry.toml is now the NEXT, in-development (unpublished) version — it must be strictly ahead of the latest published Soldeer revision. On a Solidity content change the workflow publishes that in-dev version, then bumps [package].version to the next and commits it. The gate fails loud if the in-dev version is not ahead of the registry (no more silent auto-bump).

This repo needs a one-time bump

• foundry.toml [package].version = 0.1.0
• latest published rain-sol-codegen revision = 0.1.0 (equal — not ahead)

On the next merge that changes Solidity content, autopublish will fail with:

foundry.toml [package].version (0.1.0) is not ahead of the published revision (0.1.0); the next-version lifecycle needs it to be the next UNPUBLISHED version — bump [package].version above 0.1.0.

Action: bump [package].version to 0.1.1 in foundry.toml (the next unpublished patch). After that the lifecycle self-maintains — each publish bumps ahead automatically, no manual bumps thereafter.

If this repo generates per-release artifacts keyed by version

(e.g. src/generated/*.pointers.sol deploy-address snapshots) also pass soldeer-generate-cmd: in the package-release.yaml reusable call, so the post-publish bump re-freezes them born-green. Pure library repos with nothing generated can skip this. Reference wiring: S01-Issuer/st0x.deploy#243.

Ref: rainlanguage/rainix#264

[thedavidmeister]

Conclusion: this is already done. Recommending close as completed — not superseded, not re-scoped.

Leaving it open for a human ruling rather than closing it myself.

The action this issue asks for was taken five days after it was filed

Action: bump [package].version to 0.1.1 in foundry.toml (the next unpublished patch).

Commit 3f0e3cc, 2026-07-15, "chore: bump [package].version to 0.1.1 to unblock autopublish". Its message quotes this issue's predicted gate failure verbatim:

foundry.toml [package].version (0.1.0) is not ahead of the published revision
(0.1.0); the next-version lifecycle needs it to be the next UNPUBLISHED version

And the lifecycle has self-maintained ever since, exactly as this issue predicted

After that the lifecycle self-maintains — each publish bumps ahead automatically, no manual bumps thereafter.

Six publishes since, every one an unattended Package Release: soldeer rain-sol-codegen <next> commit:

tag	commit	[package].version after
sol-v0.1.1	e2bb321	0.1.2
sol-v0.1.2	cd708c9	0.1.3
sol-v0.1.3	b30a2c6	0.1.4
sol-v0.1.4	0e8a3aa	0.1.5
sol-v0.1.5	a42d5da	0.1.6
sol-v0.1.6	c72eb89	0.1.7

Current state, verified live: main declares 0.1.7; the Soldeer registry's newest rain-sol-codegen revision is 0.1.6, uploaded 2026-08-13T19:05:33Z. Strictly ahead. The gate is satisfied and there is no manual bump left to make.

The one thing that reads as odd — sol-v0.1.6 sitting on a commit whose manifest says 0.1.7 — is the reusable working as designed, not drift. rainix-autopublish publishes the in-dev version from the pre-bump tree, commits the bump, and only then tags sol-v${{ steps.soldeer.outputs.version }}, so the tag for a published version always lands on the commit that already declares the next one.

The conditional second half does not apply, and its input is now a no-op

If this repo generates per-release artifacts keyed by version … also pass soldeer-generate-cmd:

It does not generate any. LibSnapshot — the thing that derived a tag from [package].version — was deleted in 49ffe9f on 2026-08-13. What remains is LibFs.pathForContract, which returns src/generated/<contractName>.sol with no version component, and src/generated/ holds exactly one file, CodeGennable.sol. Nothing here is keyed by version, so a bump can never open an empty slot or stale an artifact.

Independently, soldeer-generate-cmd: is now documented in rainix-autopublish as "DEPRECATED / no-op … it is ignored and will be removed." Wiring it would add a dead input.

Neither open issue supersedes this

rainlanguage/rainix#273 rules the merge-driven half explicitly out of its own scope:

Keep autopublish's soldeer publish and patch bump on merge exactly as they are. Neither should imply a deploy or a snapshot.

Its subject is the coupling between a bump and a snapshot cut. This repo has no snapshot and no deploy, so there is nothing here for it to decouple.

rainlanguage/rain.deploy#132 hosts a BuildScript base in rain.deploy and moves the deploy repos onto it. It argues at length that the base cannot live here, because cutRelease() calls freeze and freeze lives in LibRainDeploySnapshot, which would need codegen to depend on rain.deploy — a cycle. codegen has no cutRelease() and is not one of the repos being moved.

The "opposite convention" in rain.deploy is not a contradiction to reconcile

rain.deploy documents [package].version as the last publish; this repo runs it as the next. They are on different reusables, deliberately, and each states why in its own workflow. rain.deploy is on rainix-tag-release, and its package-release.yaml says:

This repo carries deployed concretes (AddressRegistry, MigrationRegistry) whose address + codehash consumers pin, which is exactly the shape rainix-tag-release exists for and exactly the shape rainix-autopublish's merge-driven, next-version lifecycle is wrong for.

This repo is the complement: a pure source-emitting library with no deployed concrete, no chain, no frozen record, and — since LibSnapshot went — nothing keyed to a release tag at all. rainix-autopublish is the lifecycle that matches it. Two conventions, one per repo shape, and this repo is on the right one.

What was checked

Fresh clone of main at af4e5a9; git log -p -- foundry.toml for the full version history; git show on 3f0e3cc and on each sol-v* tag's manifest; the live Soldeer registry API for the published revision set; rainix-autopublish.yaml@main for the gate, publish, bump and tag steps and the soldeer-generate-cmd deprecation; rain.deploy's foundry.toml and package-release.yaml for its stated convention; and the full text of rainix#273 and rain.deploy#132.

[thedavidmeister]

Closing: already complete.

The action this asked for was taken in 3f0e3cc on 2026-07-15 — "chore: bump [package].version to 0.1.1 to unblock autopublish" — whose message quotes this issue's predicted gate error verbatim. The lifecycle has self-maintained since, through six unattended Package Release commits, sol-v0.1.1 to sol-v0.1.6, each bumping the manifest one ahead. Live state: main declares 0.1.7, the registry's newest is 0.1.6 uploaded 2026-08-13T19:05:33Z. Strictly ahead, gate satisfied, nothing left to bump by hand.

The apparent puzzle in that state is not drift. rainix-autopublish publishes from the pre-bump tree, commits the bump, then tags sol-v${version} — so a sol-v0.1.6 tag sitting on a 0.1.7 manifest is the workflow working as written.

Nothing supersedes it. rainix#273 rules the merge-driven half out of its own scope in its first paragraph — "Keep autopublish's soldeer publish and patch bump on merge exactly as they are" — and targets snapshot-cutting and deploying, neither of which exists in this repo. rain.deploy#132 hosts BuildScript in rain.deploy and argues that it cannot live here at all, since cutRelease() calls freeze and freeze lives there; this repo is not one of the ones being moved.

The conditional second half does not apply either: nothing here is version-keyed. LibSnapshot was deleted in 49ffe9f, and pathForContract returns src/generated/<name>.sol with no version component. soldeer-generate-cmd: is now documented in the reusable as deprecated and a no-op.

And the rain.deploy divergence is by design rather than an inconsistency to resolve. That repo carries deployed concretes consumers pin by address and codehash, which is the shape rainix-tag-release exists for and which its own workflow says autopublish is wrong for. This repo is the complement — a pure source emitter with no concrete, no chain and no tag-keyed record — so it is on the correct reusable of the two.

Full reasoning at #issuecomment-5308427912.