How a release happens

Think services are deployed continuously rather than in big scheduled releases. There is no release night and no version everyone upgrades to at once — each service moves on its own.

How a change reaches you

1. It is merged. Every service is defined in a git repository: its configuration, its container image version, its ingress, its database. Nothing is configured by clicking around in a live system.

2. GitOps picks it up. A change to a repository is detected automatically and applied to the cluster. The running state is reconciled to match what is committed — if someone changes something by hand, it is reverted on the next sync.

3. It rolls out. Containers are replaced gradually rather than all at once, so a service stays reachable during an update. If the new version fails its health checks, the rollout stops.

4. It appears in the Changelog — if it is a change anyone would notice.

Why you will not see a version number

Because there generally is not one that means anything to you. Some services update themselves within a major version, some are pinned to an exact version and moved deliberately, and dependency updates are proposed automatically and reviewed before merging.

What matters is the changelog: it describes what changed in terms of what you can now do, not which container tag moved.

What "Production" means

Every service carries a lifecycle stage — Alpha, Beta, Production or Deprecated — documented on the lifecycle page. Production means it is expected to work and is covered by the service level documented for it. Beta means it is real but still moving.

Something broke after an update?

Report it on the Bug Reports board and say when it started. "This worked yesterday" is genuinely useful information — it narrows a search to a single change.