Coding Standard

All our code is peer reviewed before being merged and then released.
All commits should include a JIRA reference so that we can trace back the reasons for the change etc.

Breaking changes

We follow these principles for each of our endpoints:

• We do not take anything away
• We do not change processing rules
• We do not make optional things required
• Anything we add must be optional

Consumers need to be resilient enough to support these changes, e.g. they shouldn’t bind tightly to an expected representation as new fields may be added at a later date.

This means that a new endpoint should be added instead of making a breaking change to an existing endpoint.
Since we know what clients call which endpoints we can then inform the clients to switch to the new endpoint.
When all the clients have switched over we can then remove the old endpoint.

Releases

We will endeavour to release as soon as a new feature has been tested, rather than bulking up multiple changes into a release.
If an application release contains multiple changes since the last release then it is important that agreement with all the changers is sought before release.
A changelog will be generated containing all the changes since the last release to production and it will be posted in the appropriate slack channel.

_{This page was last reviewed on 04-Sep-2024, next review will be on 04-Dec-2024.}