chore: Bump app version to 0.1.0

[bbaarriiss]

Bump app version to 0.1.0 🎉

[claude]

Review: chore: Bump app version to 0.1.0

Nice milestone 🎉 The change itself is correct and minimal — version = "0.1.0" in build.gradle.kts:14. A few notes, mostly about things around the bump rather than the line itself.

Verified: no build/runtime breakage

• shadowJar pins archiveFileName.set("github-app.jar") (build.gradle.kts), so the artifact name is independent of version. The Dockerfile COPY --from=build-env /app/build/libs/github-app.jar path stays valid. 👍
• A grep over src/main/kotlin finds no runtime reads of the project version, so nothing else shifts behaviourally.

Version drift with the Helm chart

helm/githubapp/Chart.yaml still carries:

version: 0.0.1
appVersion: "0.0.1"

This matters beyond cosmetics, because appVersion is load-bearing in two places:

• helm/githubapp/templates/statefulset.yaml:33 — image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
• helm/githubapp/templates/_helpers.tpl:40 — the app.kubernetes.io/version label

helm/githubapp/values.yaml defines no image.tag, so any install that does not pass values-prod.yaml (which pins tag: "sha-9efe83d") resolves to quay.io/wire/github-app:0.0.1 — a tag that is never published, since .github/workflows/staging.yml only pushes type=sha,format=short. That is a pre-existing latent issue rather than something this PR introduces, but the bump makes the drift concrete and it is cheap to address here.

Suggestions, in order of preference:

1. Bump Chart.yaml appVersion to "0.1.0" (and the chart version per your chart-release policy) in this PR, so app version and deployment metadata stay in lockstep.
2. Separately, consider setting an explicit default image.tag in values.yaml (or making the chart fail fast when it is unset) so the Chart.AppVersion fallback cannot silently resolve to a non-existent tag.

Release hygiene for a 0.0.1 to 0.1.0 bump

git tag returns nothing and there is no CHANGELOG.md. For a version bump framed as a release, it would be useful to:

• tag v0.1.0 on merge, and/or cut a GitHub Release;
• record what changed since 0.0.1 — otherwise the version number carries no information for anyone reading it later.

If you would rather not maintain this by hand: the version now lives in two files with no automation keeping them aligned. A small CI check, or deriving the Helm appVersion from the Gradle version at package time, would prevent the next drift.

Version is not observable at runtime

Because images are sha-tagged, there is currently no way to ask a running instance which app version it is. Exposing the Gradle version through a /version or health payload (e.g. a generated build-info resource or a JAR manifest attribute) would make 0.1.0 useful operationally. Out of scope for this PR — flagging it as the natural follow-up to adopting semantic versioning.

Not applicable here

• Security: no attack surface touched; no dependency, credential, or endpoint changes.
• Performance: none.
• Test coverage: no test changes needed — nothing asserts on the version string, and adding such an assertion would not be valuable. I did not run the Gradle build, since a version literal change cannot affect compilation and the artifact name is hardcoded as noted above.

Overall: happy to see this land. The only thing I would genuinely ask for before merge is the Chart.yaml appVersion alignment, since that value feeds a real image tag.

---

Note: this repo has no CLAUDE.md, so I reviewed against the conventions visible in the existing Gradle/Helm/CI setup. If you would like reviews to follow specific house rules, adding one would help.