docs/en/changes/changes.md - skywalking-swck - Git at Google

 ## 0.12.0

 #### Features

 #### Bugs
 - Log in to Docker Hub as `docker.io`, not `registry-1.docker.io`. Both names resolve to the same registry and either can be pulled from anonymously, but the credential is stored under the host you logged in as while a push normalises the reference back to Docker Hub's canonical host -- so the chart push looked up a credential that had never been written there and would have failed with a 401. `apache/skywalking` uses `docker.io` throughout for this reason. The docs and the chart's NOTES use the same name now.
 - Publish snapshots to GHCR and releases to Docker Hub, and nothing to both, with the workflow's jobs named for the path they serve -- `publish-snapshot-images`, `publish-snapshot-chart`, `publish-release-image`, `publish-release-chart`. The per-component images and the GHCR chart were pushed on the release path too, so a release also produced `ghcr.io/apache/skywalking-swck/operator:<version>` -- artifacts nobody asked for, published from a job whose failure then blocked the release. They are snapshot-only now, and a release publishes the combined image and the chart to Docker Hub.
 - Fetch the release tarball from `dist/release`, which is where the svn move puts it and is servable immediately. `Dockerfile.release` downloaded it from `archive.apache.org` instead -- a copy that holds every release ever made but takes hours to receive a new one -- so a just-voted release could not be built until the archive caught up, and both `release-passed.sh` and the publish workflow sat in long polls waiting for it, up to an hour and thirty minutes respectively. Neither wait was for anything the build reads.
 - Take `release-passed.sh`'s default version from `dist/dev` rather than from `Chart.yaml`. By the time a vote passes, `release.sh` has already opened the next-version PR and it is usually merged, so `Chart.yaml` holds the version *after* the one being released -- pressing Enter at the prompt tried to publish a candidate that does not exist. It failed, but several prompts later and with an svn path error rather than an explanation. The script now reads what is actually waiting in `dist/dev`, refuses to guess when there is more than one candidate, and checks the chosen version exists before asking whether the vote passed.

 #### Chores
	## 0.12.0

	#### Features

	#### Bugs
	- Log in to Docker Hub as `docker.io`, not `registry-1.docker.io`. Both names resolve to the same registry and either can be pulled from anonymously, but the credential is stored under the host you logged in as while a push normalises the reference back to Docker Hub's canonical host -- so the chart push looked up a credential that had never been written there and would have failed with a 401. `apache/skywalking` uses `docker.io` throughout for this reason. The docs and the chart's NOTES use the same name now.
	- Publish snapshots to GHCR and releases to Docker Hub, and nothing to both, with the workflow's jobs named for the path they serve -- `publish-snapshot-images`, `publish-snapshot-chart`, `publish-release-image`, `publish-release-chart`. The per-component images and the GHCR chart were pushed on the release path too, so a release also produced `ghcr.io/apache/skywalking-swck/operator:<version>` -- artifacts nobody asked for, published from a job whose failure then blocked the release. They are snapshot-only now, and a release publishes the combined image and the chart to Docker Hub.
	- Fetch the release tarball from `dist/release`, which is where the svn move puts it and is servable immediately. `Dockerfile.release` downloaded it from `archive.apache.org` instead -- a copy that holds every release ever made but takes hours to receive a new one -- so a just-voted release could not be built until the archive caught up, and both `release-passed.sh` and the publish workflow sat in long polls waiting for it, up to an hour and thirty minutes respectively. Neither wait was for anything the build reads.
	- Take `release-passed.sh`'s default version from `dist/dev` rather than from `Chart.yaml`. By the time a vote passes, `release.sh` has already opened the next-version PR and it is usually merged, so `Chart.yaml` holds the version after the one being released -- pressing Enter at the prompt tried to publish a candidate that does not exist. It failed, but several prompts later and with an svn path error rather than an explanation. The script now reads what is actually waiting in `dist/dev`, refuses to guess when there is more than one candidate, and checks the chosen version exists before asking whether the vote passed.

	#### Chores