chore: release 0.2.1 #23

Merged
day01 merged %!d() commits from %!s() into %!s() 2026-08-03 17:51:55 +00:00
Owner

Bumps VERSION, Cargo.toml, Cargo.lock and the pull command in the README.

What 0.2.1 carries over 0.2.0:

  • the reporting fix that took control-plane reporting off the job critical path,
    already measured as the 0.2.1 RC column in docs/benchmarks.md;
  • the job base image served from syncode.sh instead of docker.gitea.com;
  • crate::protocol renamed to crate::gitea_protocol;
  • the CI work: registry build cache, path filters, cancelled superseded builds,
    the compatibility suite on a schedule, license and attribution.

docs/benchmarks.md keeps saying 0.2.1 RC. That file records what was
measured, and what was measured was a release candidate — the benchmark
procedure is explicit that a tag is not a version and that digests are what
identify a build.

One gap this bump exposes: nothing checks that VERSION and the Cargo.toml
version agree. The tag guard in build-image.yml compares the git tag against
VERSION only, so a forgotten Cargo.toml would ship an image labelled 0.2.1
whose syncode-runner --version still says 0.2.0. Worth a check; say the word
and I will add one.

Release sequence after this merges: develop into main, wait for the main
build to publish main and latest, then tag v0.2.1 so the promote step
copies those manifests to the SemVer tags. The infra pins in meta follow.

Bumps `VERSION`, `Cargo.toml`, `Cargo.lock` and the pull command in the README. What 0.2.1 carries over 0.2.0: - the reporting fix that took control-plane reporting off the job critical path, already measured as the `0.2.1` RC column in `docs/benchmarks.md`; - the job base image served from syncode.sh instead of docker.gitea.com; - `crate::protocol` renamed to `crate::gitea_protocol`; - the CI work: registry build cache, path filters, cancelled superseded builds, the compatibility suite on a schedule, license and attribution. `docs/benchmarks.md` keeps saying `0.2.1` RC. That file records what was measured, and what was measured was a release candidate — the benchmark procedure is explicit that a tag is not a version and that digests are what identify a build. One gap this bump exposes: nothing checks that `VERSION` and the `Cargo.toml` version agree. The tag guard in `build-image.yml` compares the git tag against `VERSION` only, so a forgotten `Cargo.toml` would ship an image labelled 0.2.1 whose `syncode-runner --version` still says 0.2.0. Worth a check; say the word and I will add one. Release sequence after this merges: `develop` into `main`, wait for the main build to publish `main` and `latest`, then tag `v0.2.1` so the promote step copies those manifests to the SemVer tags. The infra pins in `meta` follow.
day01 added 1 commit 2026-08-03 13:54:17 +00:00
		The release carries the reporting fix that kept the control plane off the job
critical path, the job base image served from syncode.sh, and the named Gitea
protocol re-export.
	
day01 merged commit ae22e7f15f into %!s() 2026-08-03 17:51:55 +00:00
day01 deleted branch chore/version-0.2.1 2026-08-03 17:51:58 +00:00
Sign in to join this conversation.
No Reviewers
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: syncode/runner#23