Shall we consider setting the default region as `us-east-1`?

[jizusun]

This what backstage does.

https://github.com/backstage/backstage/blob/999936b3915d807206f833f44c8397775780a22e/packages/backend-common/src/reading/AwsS3UrlReader.ts#L50

export const DEFAULT_REGION = 'us-east-1';

Shall we consider this?

With this approach, the region is not a breaking change any more.

[heyLu]

I suppose following what Backstage does might be a good idea, although it does feel like a bit of a workaround that was just added to work with the new aws-sdk version.

We don't use AWS S3 internally, thus the region value does not actually matter to us, so do feel free to open a PR that adds us-east-1 as a default.

With this approach, the region is not a breaking change any more.

I don't quite understand this, what do you mean by the region being a breaking change?

[jizusun]

I suppose following what Backstage does might be a good idea, although it does feel like a bit of a workaround that was just added to work with the new aws-sdk version.

We don't use AWS S3 internally, thus the region value does not actually matter to us, so do feel free to open a PR that adds us-east-1 as a default.

With this approach, the region is not a breaking change any more.

I don't quite understand this, what do you mean by the region being a breaking change?

Because when I check the release page https://github.com/spreadshirt/backstage-plugin-s3/releases/tag/%40spreadshirt%2Fbackstage-plugin-s3-viewer-common%400.3.0
It says

e83665c: BREAKING: Migrated to AWS-SDK version 3. Now the platform config requires a new field called region. If not present, the plugin will fail on startup.

So it's a breaking change, isn't it?

[heyLu]

Ah yes, that makes sense. :) If a default is introduced then there will still have been a breaking change, but not if you skip the version with the required region parameter and go directly to one with a new default.