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.