chadtmiller.com/knotless

Switch repository

Loading…

What changes

Prod's deploy now sets KNOTLESS_CLIENT_MINIMUM to 0.6.0, with a reason. dev.knotless.describeServer answers it, and clients older than 0.6.0 refuse to run until they run knotless upgrade.

Why

0.6.0 deletes a deleted ref's record and starts a new ref at the time. An older client making a branch again under a name deleted within the day starts it at generation 1. It can then hit the earlier ref's claim and have its pushes refused. 0.6.0 is published, so every client can upgrade to it.

How it was checked

https://knotless.dev/releases/latest answers 0.6.0. The deploy writes both variables into the host's env file, as deploy.sh does for the others.

Shortcomings

A client checks the minimum at most once a day, so an older one can keep running for up to a day.

🤖 Generated with Claude Code

This sets KNOTLESS_CLIENT_MINIMUM to 0.6.0 and a reason in the deploy workflow's env block. I checked that deploy.sh already writes both variables into /etc/knotless/.env when they are set, and that docker-compose.yml passes them to --client-minimum and --client-minimum-reason. So the change is only the two env lines, and the plumbing was already in place. The reason string is quoted correctly in YAML. I found nothing that needs to change.

I did not check that knotless.dev/releases/latest answers 0.6.0. I took that from the description. The one-day lag before older clients see the minimum is acknowledged in the description.