Skip to content

Commit 445392b

Browse files
authoredJan 2, 2025
chore(apiversion): add guidelines regarding bumping apiversion (coder#16009)
Adds some package-level documentation to reduce confusion on when it is appropriate or warranted to bump apiversions.
1 parent 18600d3 commit 445392b

File tree

1 file changed

+26
-0
lines changed

1 file changed

+26
-0
lines changed
 

‎apiversion/doc.go

+26
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,26 @@
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

0 commit comments

Comments
 (0)
Please sign in to comment.