search

google / go-cloud

The Go Cloud Development Kit (Go CDK): A library and tools for open cloud development in Go.
https://gocloud.dev/
Apache License 2.0
9.57k stars 812 forks source link

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

Closed vangent closed 3 months ago

vangent commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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).