Shall we consider setting the default region as `us-east-1`?
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.
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?
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-1as 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
https://github.com/spreadshirt/backstage-plugin-s3/commit/e83665c0323d49f0e3646a2e632ddf530a745fbf: 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?
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.