Release notes and compatibility history

Prerequisites and authority

Use this reference with your installed release. Internal implementation routes and settings are not public integration contracts.

Record release compatibility

Each published article must identify applicable product version(s) and last verified date. Drafting date is not technical verification. Until a build is tested, these drafts retain pending verification metadata.

For each release, record product version/commit, installer package/checksum, OS/architecture, Docker/runtime requirements, schema revision, tested RouterOS firmware, supported interfaces/features and known limitations.

Release notes should state the concrete changed behavior, upgrade path, migration risk, approval requirements, expected interruption, rollback limits and post-update acceptance. Link the exact matching downloads and documentation revision.

Maintain older compatible guides when historical installations remain supported. Do not silently replace an old installation command with a new one under the same compatibility claim.

A source APP_VERSION default is not the deployed release identity. Use the installed package/runtime/manifest record and reconcile disagreements. Mixed service versions after a failed update must be resolved before verification is accepted.

Article PDFs, category manuals and offline bundles must derive from the same approved revision. This package is an editorial review bundle; production exports and publishing remain a later gate.

Related guides

Related guides: Configuration reference (env vars, ports, URLs), Docker services, Compose files and persistent volumes, Database diagnostics and safe query reference, Subscription and provisioning state model.