You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/sdks/manage/versioning.mdx
+31-7Lines changed: 31 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,37 +11,45 @@ Speakeasy-generated SDKs are automatically versioned using Semantic Versioning (
11
11
12
12
## Versioning logic
13
13
14
-
The SDK version will be automatically incremented in the following cases.
14
+
The SDK version is automatically incremented based on three independent inputs: generator feature changes, OpenAPI document changes, and configuration changes. Each input is evaluated separately, and the largest bump across all three wins.
15
+
16
+
The precedence order is: **major > minor > patch**. For example, if generator features trigger a minor bump and the OpenAPI document triggers a major bump, the final result is a major bump.
15
17
16
18
### Generator version changes
17
19
18
20
When Speakeasy releases a new generator version, it compares the features changed in the new generator to those used in the SDK:
19
21
20
22
- If multiple used features in the SDK change, the largest version bump (major, minor, patch) across all used features determines the version increment.
23
+
- If a generator feature that was previously tracked in `gen.lock` is no longer present, that triggers a minor bump.
21
24
- Features unaffected by the new generator version maintain the current version.
22
25
23
26
### Configuration changes
24
27
25
28
- Changes to the `gen.yaml` file will bump the patch version.
26
-
- Changes to the checksum will also bump the patch version.
29
+
- Changes to the configuration checksum will also bump the patch version.
27
30
28
31
### OpenAPI document changes
29
32
30
-
- If the `info.version` section of the OpenAPI document is SemVer compliant, major or minor changes to the OpenAPI document will bump the major or minor version of SDKs correspondingly.
31
-
-_Coming Soon_: Speakeasy will detect changes to the OpenAPI document (for example, adding a breaking change to the parameters of an operation) and bump versions accordingly.
33
+
Versioning based on OpenAPI document changes works by comparing the `info.version` field between generations:
34
+
35
+
- If the `info.version` field is a valid SemVer string, Speakeasy compares the previous and current values. A major or minor increment in `info.version` bumps the SDK version correspondingly.
36
+
- If `info.version` is not present, is not a valid SemVer string, or has not changed, Speakeasy falls back to a document checksum comparison. A checksum change triggers a patch bump.
37
+
- Speakeasy does not currently analyze the actual content of the OpenAPI document (such as added or removed operations). Only the `info.version` field and the overall document checksum are evaluated.
32
38
33
39
## Pre-release version bumps
34
40
35
41
Speakeasy supports any SemVer-compatible string as a valid version, including pre-release versions such as `X.X.X-alpha` or `X.X.X-alpha.X`.
36
42
37
-
-Pre-release versioning continues until manual removal.
38
-
-Automated bumps increment pre-release versions. For example, `1.0.0-alpha`, `1.0.0-alpha.1`, `1.0.0-alpha.2`.
39
-
- To exit pre-release versioning, set a new version or run `speakeasy bump graduate`.
43
+
-When the current version has a pre-release suffix (for example, `1.0.0-alpha.1`), automated bumps increment the pre-release counter instead of the main version segments. For example: `1.0.0-alpha` → `1.0.0-alpha.1` → `1.0.0-alpha.2`.
44
+
-Pre-release versioning continues until explicitly exited.
45
+
- To exit pre-release versioning, set a new version manually, run `speakeasy bump graduate`, or set the `SPEAKEASY_BUMP_OVERRIDE` environment variable to `graduate`. A `graduate` bump strips the pre-release suffix entirely, promoting `1.0.0-alpha.2` to `1.0.0`.
40
46
41
47
## Major version bumps
42
48
43
49
New SDKs start at version `0.0.1`. Automatic major version bumps begin after reaching version `1.0.0`. Breaking changes trigger major version increments after `1.0.0`.
44
50
51
+
When a major bump is detected for a pre-v1 SDK (version below `1.0.0`), Speakeasy automatically downgrades it to a minor bump. This also applies to Go SDKs regardless of version, because major version changes in Go require import path changes that significantly impact downstream users. This automatic downgrade does not apply when the bump was explicitly set via `SPEAKEASY_BUMP_OVERRIDE=major`.
52
+
45
53
Major version changes affect the Golang SDK migration path.
46
54
47
55
### Golang major version bumps
@@ -53,6 +61,22 @@ Golang module versions above `1.0.0` require import path changes to include the
53
61
54
62
Consider Golang SDK major version changes carefully due to migration path impacts. The SDK maintainer determines when to increment major versions.
55
63
64
+
## Overriding automatic versioning with an environment variable
65
+
66
+
Set the `SPEAKEASY_BUMP_OVERRIDE` environment variable to force a specific bump type, bypassing all automatic detection. Valid values are `patch`, `minor`, `major`, and `graduate`.
67
+
68
+
When set, this variable clears any bumps detected from generator features, OpenAPI document changes, or configuration changes, and applies only the specified bump type.
69
+
70
+
```bash
71
+
# Force a minor bump regardless of detected changes
72
+
SPEAKEASY_BUMP_OVERRIDE=minor speakeasy run
73
+
74
+
# Force graduation from pre-release
75
+
SPEAKEASY_BUMP_OVERRIDE=graduate speakeasy run
76
+
```
77
+
78
+
This is useful in CI/CD pipelines that require deterministic version control. Unlike the automatic major-bump downgrade for pre-v1 and Go SDKs, `SPEAKEASY_BUMP_OVERRIDE=major` applies the major bump as specified without any downgrade.
79
+
56
80
## Disabling automatic versioning
57
81
58
82
To permanently disable automatic version bumping, set `versioningStrategy` to `manual` in the `generation` section of your `gen.yaml` file:
0 commit comments