Skip to content

Commit 53923de

Browse files
authored
Add versioning policy doc (aws#4468)
1 parent fa3fcca commit 53923de

File tree

1 file changed

+33
-0
lines changed

1 file changed

+33
-0
lines changed

Diff for: VERSIONING.md

+33
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,33 @@
1+
# Versioning Policy
2+
3+
The AWS SDK for Java v2 uses a versioning scheme that follows the format: `MAJOR.MINOR.PATCH[-QUALIFIER]`. Revisions to different version components communicate the risk associated with changes when upgrading to newer versions of the SDK:
4+
5+
* `MAJOR` - Huge changes, expect API incompatibilities and other breaking changes.
6+
* `MINOR` - Medium risk changes. Upgrading SHOULD usually just work but check the [release notes](CHANGELOG.md). Example changes might include incrementing minimum Java version, deprecating APIs, or significant changes to core runtime components. Changes to `MINOR` version MAY contain backwards incompatible changes under certain scenarios.
7+
* `PATCH` - Zero to low risk changes. New features and bug fixes that should be safe to consume without much worry.
8+
* `QUALIFIER` - (Optional) Additional release version qualifier (e.g. PREVIEW). Most releases are not expected to have a qualifier.
9+
10+
The AWS SDK for Java v2 does NOT follow strict [semantic versioning](https://semver.org/). Patch releases may contain new features in addition to bug fixes. See the FAQ for rationale.
11+
12+
## Stability of the AWS SDK for Java
13+
14+
For information about maintenance and support of SDK major versions and their underlying dependencies, see the
15+
following in the AWS SDKs and Tools Shared Configuration and Credentials Reference Guide:
16+
17+
* [AWS SDKs and Tools Maintenance Policy](https://docs.aws.amazon.com/credref/latest/refdocs/maint-policy.html)
18+
* [AWS SDKs and Tools Version Support Matrix](https://docs.aws.amazon.com/credref/latest/refdocs/version-support-matrix.html)
19+
20+
21+
## Component Versioning
22+
23+
The SDK versions all service clients (e.g. `S3`, `EC2`, `DynamoDb`, etc) and the runtime (e.g. `aws-config`) together under a single version. This allows customers to easily upgrade multiple SDK clients at once and keep dependencies, such as the core runtime, compatible. The SDK may in the future consider versioning service clients separately from one another.
24+
25+
## Internal APIs
26+
27+
Any API marked with either `@SdkInternalApi` or `@SdkTestInternalApi` is not subject to any backwards compatibility guarantee. These are meant to be consumed only by the SDK and may be changed or removed without notice. The SDK MAY bump the `MINOR` version when making such a change.
28+
29+
## FAQ
30+
31+
**Why does the SDK not follow semantic versioning (semver)?**
32+
33+
Under semver we’d NEVER use the `PATCH` component. The SDK does *daily* releases containing updates to AWS service models. These changes go out with bug fixes every day. That means for us and customers the `PATCH` version would just be useless, it would always be zero. The intention behind this versioning scheme is to allow customers to weigh the relative risk and/or cost associated with updating to a newer SDK version.

0 commit comments

Comments
 (0)