chore: release 0.7.0

CHANGELOG.md

@@ -1,5 +1,16 @@
 # Changelog
 
+## [v0.7.0] - 2026-09-23
+
+### Added
+
+- Session owners can read, validate and update the TOML configuration of each
+  component in a running agent; admins can do the same for the platform stack.
+  VTA-only agents expose only their VTA configuration.
+- Applying a change restarts only the selected component and checks its
+  readiness. If writing or starting it fails, the API attempts to restore the
+  previous configuration and restart the component.
+
 ## [v0.6.1] - 2026-09-21
 
 ### Changed

docs/release.md

@@ -17,16 +17,16 @@ version on the shelf; something else has to take it off.
 `Chart.yaml` holds the only version number:
 
 ```yaml
-version: 0.1.0
-appVersion: "0.1.0"
+version: 0.7.0
+appVersion: "0.7.0"
 ```
 
 The two are kept equal and one release bumps both. `make release` reads
-`version` from this file — nothing else needs editing, and the image tag and the
-chart version therefore cannot disagree.
+`version` from this file, so the image tag and the chart version cannot
+disagree. Add the release notes to `CHANGELOG.md` at the same time.
 
-This repo and `vtafarm` version independently. There is no reason for the two to
-be on the same number.
+This repo and `vtafarm` have separate version numbers. Check the frontend
+changelog for its required API version before releasing them together.
 
 While this is 0.x the values structure may change in any release. Anything that
 would make an existing `values.yaml` behave differently belongs under
@@ -53,38 +53,56 @@ gh auth refresh -h github.com -s write:packages -s read:packages
 
 ## Steps
 
-Run them in this order. Steps 1 and 2 must not have any other commit between
-them: the changelog, the version, the tag and the artifacts all have to describe
-the same tree.
+Run them in this order. `main` requires the `✍️ Sign-off` status check, which
+runs on pull requests, and this repository uses squash merges. Prepare each
+release on a branch, merge it, and tag the resulting commit on `main`. The tag
+and the artifacts must describe that same tree.
 
-**1. Write the changelog and bump the version, in one commit.**
+**1. Create a release branch, then write the changelog and bump the version in
+one commit.**
 
 ```bash
+git switch main
+git pull --ff-only
+git switch -c chore/release-0.7.0
 vim CHANGELOG.md                     # add the new version's entry
 vim helm/vtafarm-api/Chart.yaml      # version and appVersion
-git add CHANGELOG.md helm/vtafarm-api/Chart.yaml
-git commit -s -m "chore: release 0.2.0"
+git add CHANGELOG.md helm/vtafarm-api/Chart.yaml docs/release.md
+git commit -s -m "chore: release 0.7.0"
 ```
 
-**2. Tag that commit.**
+**2. Push the branch, open a pull request and wait for its checks.**
 
 ```bash
-git tag -s v0.2.0 -m "vtafarm-api 0.2.0"
+git push -u origin chore/release-0.7.0
 ```
 
-Signed (`-s`), so GitHub shows the tag as verified rather than unverified. This
-repo signs its commits already; `git config tag.gpgsign true` extends that to
-tags so a plain `git tag -a` signs too.
+Open the pushed branch on GitHub, create a pull request targeting `main`, and
+wait for the `✍️ Sign-off` check to pass. Merge it on GitHub with **Squash and
+merge**. Do not create the version tag on the release branch: squash merging
+creates a different commit on `main`.
+
+**3. Update `main` and tag the merged commit.**
+
+```bash
+git switch main
+git pull --ff-only
+git tag -s v0.7.0 -m "vtafarm-api 0.7.0"
+```
+
+The tag is signed (`-s`), so GitHub shows it as verified rather than
+unverified. This repo signs its commits already; `git config tag.gpgsign true`
+extends that to tags so a plain `git tag -a` signs too.
 
 The `v` prefix is used everywhere a person reads the version — the git tag, the
 GitHub release, the changelog heading. `Chart.yaml` and the artifacts it names
 stay bare, which is the Helm and OCI convention.
 
-Tag before building. If the build fails, `git tag -d v0.2.0` and retry; an
+Tag before building. If the build fails, `git tag -d v0.7.0` and retry; an
 untagged successful release is the worse failure, because nothing points at the
 commit the artifacts came from.
 
-**3. Build and publish.**
+**4. Build and publish.**
 
 ```bash
 make release
@@ -93,31 +111,31 @@ make release
 This runs:
 
 ```bash
-docker buildx build --platform linux/amd64 -t ghcr.io/ic3software/vtafarm-api:0.2.0 --push .
+docker buildx build --platform linux/amd64 -t ghcr.io/ic3software/vtafarm-api:0.7.0 --push .
 helm package helm/vtafarm-api -d .charts
-helm push .charts/vtafarm-api-0.2.0.tgz oci://ghcr.io/ic3software/charts
+helm push .charts/vtafarm-api-0.7.0.tgz oci://ghcr.io/ic3software/charts
 ```
 
 `--platform linux/amd64` is not optional. The cluster nodes are x86; a release
 built on an arm64 machine without it produces an image that fails to start with
 `exec format error`.
 
-**4. Push the commit and the tag.**
+**5. Push the tag.**
 
 ```bash
-git push origin main
-git push origin v0.2.0
+git push origin v0.7.0
 ```
 
-`git push origin main` does not carry tags. They need their own push.
+The pull request already updated `main`. Git does not include tags with that
+update, so the version tag needs its own push.
 
-**5. Create the GitHub release.**
+**6. Create the GitHub release.**
 
 Pass only the new version's section, not the whole changelog:
 
 ```bash
-awk '/^## \[v0\.2\.0\]/{f=1;next} f && /^## \[/{exit} f' CHANGELOG.md \
-  | gh release create v0.2.0 --notes-file -
+awk '/^## \[v0\.7\.0\]/{f=1;next} f && /^## \[/{exit} f' CHANGELOG.md \
+  | gh release create v0.7.0 --notes-file -
 ```
 
 Only the version in the first pattern changes between releases. `next` drops the
@@ -130,8 +148,8 @@ Omitting `--title` makes the title the tag name, which is the convention.
 ## Verifying
 
 ```bash
-helm show chart oci://ghcr.io/ic3software/charts/vtafarm-api --version 0.2.0
-docker manifest inspect ghcr.io/ic3software/vtafarm-api:0.2.0 | grep architecture
+helm show chart oci://ghcr.io/ic3software/charts/vtafarm-api --version 0.7.0
+docker manifest inspect ghcr.io/ic3software/vtafarm-api:0.7.0 | grep architecture
 ```
 
 The architecture must be `amd64`.
@@ -165,7 +183,8 @@ immutable: never re-push a version that already exists, bump instead.
 
 | Failed at | Recovery |
 | --- | --- |
-| Before `make release`, tag not pushed | `git tag -d v0.2.0`, fix, start again |
+| Before the pull request is merged | Fix the release branch, commit with `-s`, push and wait for the checks again |
+| After merge, before `make release`, tag not pushed | `git tag -d v0.7.0`; fix through another pull request, then tag the new `main` commit |
 | Image pushed, chart failed | Fix and re-run `make release` — the image push is idempotent for the same content |
 | Both pushed, then a bug is found | Do not overwrite. Release the fix as the next version |
 | Tag already pushed | Leave it. Moving a published tag needs a force push, which this repo does not do |

helm/vtafarm-api/Chart.yaml

@@ -3,5 +3,5 @@ name: vtafarm-api
 description: VTA Farm API — Go REST backend for Kubernetes pod management
 type: application
 # Kept equal; one release bumps both.
-version: 0.6.1
-appVersion: "0.6.1"
+version: 0.7.0
+appVersion: "0.7.0"