Description
Describe the feature
Due to our org maintenance policy a major version bump is not currently considered a possibility for the JSv3 SDK.
Increasing the major version of an SDK indicates that this SDK underwent significant and substantial changes to support new idioms and patterns in the language. Major versions are introduced when public interfaces (e.g. classes, methods, types, etc.), behaviors, or semantics have changed. Applications need to be updated in order for them to work with the newest SDK version. It is important to update major versions carefully and in accordance with the upgrade guidelines provided by AWS.
This blocks us from incrementing the major version for unavoidable changes such as:
- dropping support for a major Node.js version.
- significant changes to internals
- Endpoints 2.0
- various Smithy Reference Architecture components
- moving dependencies to peer
I propose that we adhere to semver by using the major version increment to denote breaking changes such as the above. The product name will remain "AWS SDK for JavaScript (v3)", but the major version can increment freely.
Use Case
We are required at times to make changes that are considered breaking changes, but we are not able to increment the major version.
Users should be able to safely take a ^X.Y.Z dependency on the SDK.
Proposed Solution
Detach the product iteration version or product name "v3" from the version string. Allow incrementing the major version.
Other Information
Expected questions:
-
Will this clash with the possible future release of AWS SDK for JavaScript (v4)?
- Yes, it may. If a drastic rewrite is needed for a hypothetical v4, use a different NPM package name and repository.
- It will be potentially confusing if you have, e.g.
@aws-sdk/[email protected]and then@aws-sdk-v4/[email protected]. But, this is not an insurmountable issue and the current problems with a locked major version outweigh this hypothetical problem.
-
Will developers being able to make breaking changes whenever in fact increase the number of breaking changes, since a restraining factor was removed?
- I propose that we only use major version increment when an unavoidable change occurs such as deprecating a major Node.js version.
- The maintainers should carefully review each increment of the major version.
- We will not increment the major version solely to cosmetically improve the public interface.
As a reference, front-end developers may recall when "Angular 2" became "Angular" and is now at version 17.0.0.
Acknowledgements
- I may be able to implement this feature request
- This feature might incur a breaking change
SDK version used
3
Environment details (OS name and version, etc.)
all