Skip to content

Release Notes

Applies to: All subscriptions

Purpose

Tell a customer what changed and, more importantly, whether they must act. A release note that lists changes without stating obligations makes the reader do the analysis, and they will get it wrong.

Audience

Administrators, integration developers, implementation partners.

Prerequisites

None. Release notes are read before deciding to upgrade.

Steps

How to read a release note

Each entry is organised by what it requires of you, not by component:

Section Read it if
Action required Always. This is the section that decides your upgrade plan
Breaking changes You have an integration
Deprecations You want to avoid future work
New features You want to use them
Fixes You reported something, or want to know what changed
Known issues Always, before upgrading

Before any upgrade

Step Why
Read notes for every intervening version Obligations accumulate. Skipping versions is normal; skipping their notes is not
Note every action required These become upgrade tasks
Check breaking changes against your integrations An integration failing after an upgrade is nearly always listed here
Check known issues Some make an upgrade worth delaying
Plan the window from the actions Not from an assumption

What counts as an action

Type Example Consequence of missing it
New required configuration A new setting with no safe default The application will not start, or a feature silently does not work
A migration A schema change Startup refusal, which is the safety net working
A breaking API change A changed response shape Integrations fail
A deprecation An endpoint retiring at a future version Something stops working later
New statutory behaviour A changed validation rule Documents behave differently, correctly, and unexpectedly
A default change A flag whose default flips Behaviour changes without you changing anything

The last row is worth watching. A changed default alters behaviour on a system nobody touched, and it is the hardest kind of change to attribute after the fact.

The template

Release notes follow the format in Release Note Template. Publishing them in a consistent shape is what makes them scannable — a reader who has read one can find the action section in every other without reading the whole page.

The version scheme

Complifly releases are numbered YYYY.MM — the year and month of general availability, for example 2026.09. A corrective release within the same month takes a patch suffix: 2026.09.1.

Calendar versioning rather than semantic versioning, for a specific reason: this product's change cadence is driven by statute. When the GST Council changes a threshold, a rule or a schema, the release date is the fact a customer needs in order to reconcile their own filings, and a semantic number would hide it. "Which release were we on in September?" is a question this scheme answers and 3.4.1 does not.

The documentation version matches the release number exactly. Each release publishes its own documentation version, and the version selector in the header is how a reader on an older release reaches the pages that match it. See Documentation Lifecycle.

Where to find them

Release notes are published per release, in this section, one page per version, newest first. Retain them: they are the record of what your environment has been through, and the first thing to consult when behaviour changes and nobody knows why.

Current state — no release notes have been published

Verify: As of 2026-08-28 no Complifly release has been numbered and no release note exists. The repository carries no version tags, and the version fields in the build manifests are placeholders. G3

This is a gap, stated here rather than left to be discovered. It has one specific consequence for anyone reading this section today: there is no record of what changed between the environment you were given and the environment you are running. If behaviour differs from what a page describes, there is currently no document that would explain when it changed.

Closing it needs three things, in order, and none of them is writing prose:

  1. Number the current state. Tag the deployed code with a YYYY.MM version. Until a release has a name, a note about it has no title.
  2. Publish the first note from that tag, using the template. The first note is allowed to be short — "initial numbered release; no upgrade actions" is a complete and useful note — but it must exist, because it is the baseline every later note is read against.
  3. Make the note part of releasing, not a follow-up. A release that ships without its note has to be reconstructed from commit history later, by someone who was not there.

Validation

Check Pass condition
Notes read for every intervening version Not just the target
Actions extracted Each is an upgrade task with an owner
Breaking changes checked Against every integration
Known issues considered Explicitly, before committing to the upgrade
Notes retained Available after the upgrade

Troubleshooting

Symptom Cause Action
An integration broke after an upgrade A breaking change not checked Read the notes for every intervening version
The application will not start after an upgrade A required migration or setting missed The startup message names it
A feature silently stopped working New configuration required, not applied Check the action section
Behaviour changed with no configuration change A default changed Check for a default change in the notes
Nobody knows which version is deployed No record Record the version at every upgrade
A known issue was hit Notes not read before upgrading Read known issues before, not after