Release note policy

Every production release of the CyberOptix CTEM Platform is accompanied by a release note published to Release notes, which carries an RSS feed you can subscribe to.

This page states what we commit to. It exists so the commitment is checkable rather than implied.

What is communicated​

A release note covers anything that changes what you can do, what you must do, or what you can rely on:

Internal refactoring, dependency updates and performance work that changes no behaviour are not individually listed. Where they change something observable - a response time, a limit, an error message - they are.

Timing​

Breaking changes invert the usual order deliberately. A note published alongside a change you needed to prepare for is not notice.

Coverage​

Every production release has a note. That is enforced by the release pipeline rather than by process: a release cannot complete without one. The mechanism is not a convenience, it is what makes the commitment above true rather than aspirational.

Corrections​

Published notes are appended to, not rewritten. A correction appears as a dated addendum on the original note, so the record of what was said and when stays intact.

Approval​

Release notes land through the same reviewed change process as the code they describe. The review is the approval, and it is recorded in version control alongside the change.

Record​

A machine-readable index of every release and its note is published at /release-notes/manifest.json: version, release date, publication date, and link.

It is generated from the notes themselves rather than maintained separately, so it cannot drift from what was actually published. If you need evidence of change communication for your own audit, that file is the artifact - it is the same one we use.

Questions​

If something changed and you cannot find a note for it, that is a gap we want to know about. Contact [email protected].