Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

aws: Migrate to defaulting to V2 instead of V1. #3459

Closed
vangent opened this issue Aug 7, 2024 · 3 comments
Closed

aws: Migrate to defaulting to V2 instead of V1. #3459

vangent opened this issue Aug 7, 2024 · 3 comments

Comments

@vangent
Copy link
Contributor

vangent commented Aug 7, 2024

We currently support both in most packages. URL openers default to V1.

We should announce that we're going to change the default for URLOpeners, then wait 1-2 release or say 6 months before making the change.

We should also consider dropping support for AWSv1 entirely, but I'm hesitant to do that too proactively. I don't have any visibility into whether Go CDK users use it or not.

@Maldris
Copy link

Maldris commented Aug 7, 2024

Given the SDK behavior for invoking environment based connection and session is equivalent, I think swapping the behavior when opening via url from v1 to v2 is unlikely to create major issues (though obviously this would need to be tested).
The main considerations then would be ensuring the ?awssdk=v1 behavior works as expected.

I agree that maintaining support for V1 in the medium term would be critical to allow migration, and I suspect the V1 sdk will be in maintenance mode and in public use for a good long while, so it could still be supported by re-namespacing those provider specific constructors (i.e. OpenBucket => OpenBucketV1 and OpenBucketV2 => OpenBucket and marking the function as deprecated. This would allow the functionality to be persisted for the duration of support.

This would be a breaking change as it renames a public function, but will cause explicit notice when people update.
After some time V1 could be removed without changing the main public components of the API except for those still using V1.

The major issue will be where implementation has logic for both, excising it later could become time consuming, though again, V1 SDK support will probably be maintained for a while.

@vangent
Copy link
Contributor Author

vangent commented Aug 13, 2024

so it could still be supported by re-namespacing those provider specific constructors

I don't think that's necessary, we can just leave them as-is. There's no need to make a breaking change.
I might mark them deprecated though.

At such time when we remove support for V1 (which will be a breaking change), we can alias the non-versioned functions like OpenBucket to the V2 ones.

@vangent
Copy link
Contributor Author

vangent commented Aug 13, 2024

I've marked the V1 functions deprecated, and changed the default for URLs to V2.

When I create the next release, I'll call out the breaking change for URLs, and announce a plan to remove the support for V1 in in 6 months, and ask for feedback on the latter (we might have to keep support for longer).

@vangent vangent closed this as completed Aug 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants