5 Commits

Include renames

Author	SHA1	Message	Date
Ilker ManapandClaude Opus 5.5	abaf086fd5	A standby's portal is the leader's; the changelog as the release notes read it ... A proxy left pointing at a standby showed an empty cluster: the portal and the admin pages read the standby's own memory. A standby now passes its client port to the leader's, all but /health, /ready and /leader, which must describe the machine a load balancer is choosing; and its admin port passes the dashboard as well as the API. The leader trusts the control planes' X-Forwarded-For, so clients keep their own address. The changelog's candidate section is "Unreleased" again: release notes for an rc read that section, and v0.11.3-rc.1 got none. The e2e wait for two endpoints is 30s: under the race detector on a busy runner, 15s was missed once. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-10-05 06:34:57 +02:00
Ilker ManapandClaude Opus 5.5	5dac1854c2	Publish small fixes as release candidates of the next version ... Every fix so far became its own patch release, and the natural alternative — v0.10.3-a — sorts before v0.10.3 by SemVer's rules: a hyphen marks a pre-release, so every tool that orders versions would take the fix for the older one. A release candidate of the next version, v0.10.4-rc.1, sorts after v0.10.3 and before v0.10.4, which is what it is. CI already builds any v* tag. Its release notes now come from a "## Unreleased" section in CHANGELOG.md, where changes gather until the version they belong to is released, and the release is marked as a pre-release. Onboarding, in Go and in the shell script, counts a candidate as a release and downloads it rather than copying the operator's binary. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-09-30 01:00:11 +02:00
Ilker ManapandClaude Opus 5.5	fa7f90880d	Put the changelog on the release page ... Every release on Gitea was a list of binaries and nothing else. Gitea makes an empty release for each pushed tag, and the workflow only ever attached files to it, so what had changed was written in CHANGELOG.md and nowhere a release was looked at. A job after the build now copies the tag's section of the changelog onto its release, and fails if there is none — a version nobody described should say so where it is seen. Run by hand, it syncs every version the changelog has, which is how the releases made before this get their notes. The changelog stays the one place notes are written; this copies it. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-09-28 10:32:58 +02:00
ilkerandClaude Opus 5	f0c1ca87f1	ci: set milestone due dates at noon UTC ... 23:59:59Z renders as the following day in any positive-offset timezone, so every due date showed up a day late in the UI. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-16 01:34:05 +02:00
ilkerandClaude Opus 5	40c884a50a	Add a changelog and map releases onto roadmap phases ... Versions track the phases in the plan: a phase is released once its exit criterion is met, not when its code lands. That keeps "released" meaning something — v0.1.0 ships sim-engine and the routing libraries, and says plainly that the gateway does not serve traffic yet. scripts/gitea/milestones.py creates the matching Gitea milestones. Idempotent and never destructive, so it can be re-run after the roadmap shifts. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-16 01:29:41 +02:00