Problem Statement
A while ago the JS SDK team decided to rename their AWS Lambda Layer to include the current major in the name.
Previously: SentryNodeServerlessSDK
Currently: SentryNodeServerlessSDKv10
This was done so that users have a better understanding of what major version the lambda layer supports. AWS Lambda layers have an integer versioning system that is auto-incremented by AWS whenever we publish a new version. We can not control this and it's hard for users to correlate a specific SDK version with the layer.
We do store the exact version of the SDK in the Layer's description, but this is not as apparent as storing the major in the name directly.
We chose the major granularity over an exact version in the name because having an exact version would mean users would have to constantly re-provision their infrastructure vs just bumping a version integer.
Manually handling the major name versioning is a source of mistakes and hassle whenever we release a new major.
Brainstorm Solution
It would be nice if the version could be string interpolated into the name and we could define the layer with that, e.g. SentryNodeServerlessSDKv{{ major }} which would get interpolated to SentryNodeServerlessSDKv10 whenever we publish a v10 version of our SDKS.
Interpolation would also make it flexible for others at Sentry that do not store the version in their lambda name, e.g SentryPythonServerlessSDK
Problem Statement
A while ago the JS SDK team decided to rename their AWS Lambda Layer to include the current major in the name.
Previously: SentryNodeServerlessSDK
Currently: SentryNodeServerlessSDKv10
This was done so that users have a better understanding of what major version the lambda layer supports. AWS Lambda layers have an integer versioning system that is auto-incremented by AWS whenever we publish a new version. We can not control this and it's hard for users to correlate a specific SDK version with the layer.
We do store the exact version of the SDK in the Layer's description, but this is not as apparent as storing the major in the name directly.
We chose the major granularity over an exact version in the name because having an exact version would mean users would have to constantly re-provision their infrastructure vs just bumping a version integer.
Manually handling the major name versioning is a source of mistakes and hassle whenever we release a new major.
Brainstorm Solution
It would be nice if the version could be string interpolated into the name and we could define the layer with that, e.g.
SentryNodeServerlessSDKv{{ major }}which would get interpolated toSentryNodeServerlessSDKv10whenever we publish a v10 version of our SDKS.Interpolation would also make it flexible for others at Sentry that do not store the version in their lambda name, e.g SentryPythonServerlessSDK