Major / Minor release distinctions, and resulting change management
Major Release
Label = x.0. Example: 3.0.
Description: Software vendors need to update their software. Examples:
-
The interface changes:
-
An endpoint is changed.
-
A field is removed.
-
The structure of the response changes.
-
-
The structure of a code table changes.
-
The text of an error message changes, if the vendor’s code relies on specific text.
Minor Release
Label = x.1, x.2, x.3 etc.
Description: Software vendors don’t need to change their software. Examples:
-
A new endpoint is added.
-
Code-table data changes.
-
An API has back-end changes that don't affect the interface.
-
Specifications or other documents are updated, with no change to code.
Change Management
ACC will support a maximum of two major versions of the same API at any given time.
N: Current version
N-1: Previous version
When a new version is introduced, the current version becomes N-1 (grandfathered) and the earlier version will be retired.
ACC will endeavour to:
-
Limit API version updates.
-
Maintain a minimum of a six month interval period between major updates.*1
When an API release has been grandfathered, it will:
-
Have no further changes.
-
Be supported until it is retired.
-
Be retired at the end of six months, or when a new major release is made if that is sooner.
The sector, via the Developer Portal, will be:
-
Advised regards a plan to introduce a new, or change a version of an, API.
-
Consulted regards the design of a new, or change in an, API.
The API will be made available via the compliance environment (sandpit) to facilitate sector testing and trials.
*1: ACC reserve the right to change the interval period to accommodate business or security needs.