Please stop pinning the client libraries to a minor versions of AWSSDK.Core

[williamdenton]

I use SQS, DynamoDb, S3, Kinesis, XRay and more. We have built up library code around each of these that we publish to our own internal nuget feed.
Pinning the required version of AWSSDK.Core to 3.5 or 3.7 is super troublesome when it comes to upgrading across these "minor" versions. All packages must upgrade simultaneously as the build breaks if you try and use a 3.5 series package in the same project as a 3.7 series.

Describe the Feature

Please build some backwards compatibility into your libraries so that a client on 3.5 can use the 3.7 core library.

I'd love it if you used semver, and I realise that this might be too much of a leap right away, breaking changes belong to major versions, not odd numbered minor releases.

Is your Feature Request related to a problem?

I'm always frustrated when i one of the clients need to be updated to a new minor version, and that cascades out to ALL aws client libraries needing to be updated. This is especially irritating as the client libraries are referenced in our internal nuget packages which creates unnecessary churn. Updating one client library shouldn't force us to update ALL client libraries.

I get that sometimes you want to break some things and make all the clients use a new version, but 3 breaking changes in 9 months seems excessive.

We had the pain of upgrading from 3.3 to 3.5, and presumed you would stay on 3.5 for a while (3.3 lasted ages). Only to have to go though the pain again for 3.5 to 3.7.

Proposed Solution

Don't specify an upper limit for the AWSSDK.Core package in all the client packages. This might mean you have to build more backwards compatibility into the Core, but other vendors can do it.

Describe alternatives you've considered

Additional Context

example error messages

error NU1107: Version conflict detected for AWSSDK.Core
error NU1107: Api -> AWSSDK.Lambda 3.3.110.10 -> AWSSDK.Core (>= 3.3.107.20 && < 3.4.0)

---

This is a 🚀 Feature Request

[Kralizek]

Hi @williamdenton,
I'm not part of AWS by any mean, but I am the author of this library and it feels that many AWS customers feel your pain.

In this issue I present a workaround that works quite well for the users of my library. Kralizek/AWSSecretsManagerConfigurationExtensions#45

I hope it helps alleviate a bit the pain your team is experiencing!

[williamdenton]

yeah, thanks @Kralizek , adding newer versions of the transitive libraries works as a work around, but then when the library does get updated, the project gets project downgrade warnings as which point you have to either update the transitive again or delete it. It's just not a good experience 👍

[ashovlin]

With 48c613b we expanded the range of the Core dependency from the AWSSDK.<Service> packages to [3.7.X, 4.0). So moving forward, the 3.7.X service packages after that commit should continue working alongside Core or other services at 3.9, 3.11, etc.

For the higher-level AWS .NET libraries outside of this repo, we have moved away from the ranged dependencies. Most are currently dependent on a specific 3.7.X version of Core or AWSSDK.<Service>.

[williamdenton]

@ashovlin this sounds like a great process improvement. I'll close this issue as this new policy seems to address my gripes

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.