23.4 Versioning and Changelog Guidance

Orbnetes deployment and release orchestration documentation for operators and platform teams.

Versioning and Changelog Guidance

Versioning strategy

Use semantic versioning where possible: MAJOR.MINOR.PATCH (for example v1.4.2, v2.0.0).

When semantic versioning is not available, use immutable build identifiers (for example 2026.03.12+build.184, release-2026-03-12-rc1).

Changelog structure

Use clear sections: Added, Changed, Fixed, Security.

Example entry:

## [1.1.8] - 2026-03-10

### Added
- Added rollback policy UI support for selected version source resolution.

### Changed
- Improved release creation redirect behavior for approval-gated flow.

### Fixed
- Fixed dynamic source/tag/file loading in rollback selected version mode.

### Security
- Clarified token and credential handling guidance in documentation.

Operational guidance

  • Update changelog before release tag is published.
  • Include behavior changes, not just code internals.
  • Reference release ID/pipeline evidence for high-impact fixes.
  • Keep entries concise and operator-focused.

Recommended release note minimum

  1. What changed.
  2. Who is affected.
  3. Any migration/behavior impact.
  4. Rollback guidance if needed.

This keeps technical and operational teams aligned during rollout and incident response.