Gem updates

[etiennebarrie]

Could the tooling be changed so that gems are not published if they have no changes and just bump their dependencies on other gems of the SDK?
For example https://my.diffend.io/gems/aws-sdk-eventbridge/1.30.0/1.31.0: aws-sdk-eventbridge was bumped from 1.30.0 to 1.31.0, but with no code changes, only its dependencies changed for aws-sdk-core from 3.120.0 to 3.121.2.

Maybe I'm mistaken and there is something that needs this version at least in particular, but I don't think the gem stopped working for a project using 1.30.0, so that probably means the changes to aws-sdk-core are not really necessary?

[mullermp]

Thanks for opening up a discussion. In general we bump all versions of our gems when there are new aws-sdk-core changes or new code generation changes. Most times this is necessary for us to do.

For example, consider the changes from 3.120.0 to 3.121.2 (https://github.com/aws/aws-sdk-ruby/blob/version-3/gems/aws-sdk-core/CHANGELOG.md). For 3.121.2 it would not be feasible for us (via automation) to only bump rest-json services. And for 3.121.1 it would not be feasible to identify services with union Shape members.

It's safest for us to always bump gem versions because we can guarantee that the new service gems always build and work with the latest core, in mainline of this repo. If we don't do this, there are more testing situations where we need to consider "old" core versions and "new" service gems, or even sometimes the opposite of that.

[miketheman]

Speaking of publishing releases and changes, I've noted that this GitHub repo has Tags/Releases that stop after https://github.com/aws/aws-sdk-ruby/releases/tag/v2.11.632
How is one to determine what code is contained in a given gem, to better evaluate if something unintended has crept in to the software supply chain?

[mullermp]

Hey. Good question. Right now it's a more involved process; we browse at the API commit and look for CHANGELOG rotations (like in today's release 785412a)

I'd like to do tagged releases/commits for v3, but the biggest problem is how to do that with a modular SDK (i.e. what strategy to do). Version 2 is "monolithic" so each version has all of the clients, and was more straight forward.

Versioned release tagging is no longer possible unless we only track aws-sdk-core. We could do date based releases but each release would only have the gems updated from that release, and it doesn't help the case that you pointed out.