|
| 1 | +--- |
| 2 | +id: 3 |
| 3 | +state: approved |
| 4 | +created: 2023-03-28 |
| 5 | +placement: |
| 6 | + category: meta |
| 7 | + order: 30 |
| 8 | +--- |
| 9 | + |
| 10 | +# AIP Versioning |
| 11 | + |
| 12 | +This AIP defines the versioning scheme of the AIPs. |
| 13 | + |
| 14 | +## Guidance |
| 15 | + |
| 16 | +- The AIPs **must** be versioned by date, using the [ISO-8601 format of |
| 17 | + `YYYY-MM-DD`](https://www.w3.org/TR/NOTE-datetime), that corresponds to the |
| 18 | + date the version was added. |
| 19 | +- AIPs versions **must** be available as a tag on the source control system used |
| 20 | + to store the AIPs, of the format `v{version}`. Example: `v2023-03-28`. |
| 21 | +- The AIPs **must** have a new version when there is a significant change to one |
| 22 | + or more AIPs. |
| 23 | +- Each AIP **must** include a changelog section, with the date the change was |
| 24 | + made and a short description. |
| 25 | + |
| 26 | +## Rationale |
| 27 | + |
| 28 | +Versions serve as reference points to AIPs at a specific point in time. They are |
| 29 | +crucial since guidance on an AIP can be reversed, or include significant changes |
| 30 | +such that they are no longer similar to the original design. APIs using AIPs may |
| 31 | +need to reference older AIP guidance to justify their design choice. |
| 32 | + |
| 33 | +### Rationale for date-based versioning |
| 34 | + |
| 35 | +With date-based versioning, a client can easily find the AIP guidance at the |
| 36 | +time an API was authored. |
| 37 | + |
| 38 | +### Why not individually versioned AIPs |
| 39 | + |
| 40 | +An alternative to a universal version is to have specific versions attached to |
| 41 | +each AIP. |
| 42 | + |
| 43 | +AIPs often cross-reference one another. If each AIP had a specific version, then |
| 44 | +cross-references would also have to specify specific versions of those |
| 45 | +referenced AIPs to provide complete guidance. |
0 commit comments