|
| 1 | +// Package apiversion provides an API version type that can be used to validate |
| 2 | +// compatibility between two API versions. |
| 3 | +// |
| 4 | +// NOTE: API VERSIONS ARE NOT SEMANTIC VERSIONS. |
| 5 | +// |
| 6 | +// API versions are represented as major.minor where major and minor are both |
| 7 | +// positive integers. |
| 8 | +// |
| 9 | +// API versions are not directly tied to a specific release of the software. |
| 10 | +// Instead, they are used to represent the capabilities of the server. For |
| 11 | +// example, a server that supports API version 1.2 should be able to handle |
| 12 | +// requests from clients that support API version 1.0, 1.1, or 1.2. |
| 13 | +// However, a server that supports API version 2.0 is not required to handle |
| 14 | +// requests from clients that support API version 1.x. |
| 15 | +// Clients may need to negotiate with the server to determine the highest |
| 16 | +// supported API version. |
| 17 | +// |
| 18 | +// When making a change to the API, use the following rules to determine the |
| 19 | +// next API version: |
| 20 | +// 1. If the change is backward-compatible, increment the minor version. |
| 21 | +// Examples of backward-compatible changes include adding new fields to |
| 22 | +// a response or adding new endpoints. |
| 23 | +// 2. If the change is not backward-compatible, increment the major version. |
| 24 | +// Examples of non-backward-compatible changes include removing or renaming |
| 25 | +// fields. |
| 26 | +package apiversion |