-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(signer): graduate to stable #13661
Conversation
CloudFormation supports only one resource type for AWS Signer, namely [Signing Profile]. This is a very simple resource type with effectively two properties, both of which, have been modeled according to the latest expectations of the CDK construct library. There is no good reason why this module ought to stay as experimental. Given the standard nature of this module, I do not expect much customer feedback on usability that would require backwards incompatible changes. Hence, marking this as stable. Motivation The `ISigner` interface is referenced by the `Function` construct in the `aws-lambda` module. This is an instance of a stable module depending on an experimental module. In CDKv2, we plan to ship only stable modules as part of the mono-release of the cdk (aka, `aws-cdk-lib`). A prerequisite to achieve this is to avoid such dependencies (stable → experimental). In this specific case, we are fixing this by promoting the `aws-signer` module to stable. [Signing Profile]: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-signer-signingprofile.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Updated PR title to "feat" so it appears in changelog |
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
yay! |
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
CloudFormation supports only one resource type for AWS Signer, namely [Signing Profile]. This is a very simple resource type with effectively two properties, both of which, have been modeled according to the latest expectations of the CDK construct library. There is no good reason why this module ought to stay as experimental. Given the standard nature of this module, I do not expect much customer feedback on usability that would require backwards incompatible changes. Hence, marking this as stable. Motivation The `ISigner` interface is referenced by the `Function` construct in the `aws-lambda` module. This is an instance of a stable module depending on an experimental module. In CDKv2, we plan to ship only stable modules as part of the mono-release of the cdk (aka, `aws-cdk-lib`). A prerequisite to achieve this is to avoid such dependencies (stable → experimental). In this specific case, we are fixing this by promoting the `aws-signer` module to stable. [Signing Profile]: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-signer-signingprofile.html
CloudFormation supports only one resource type for AWS Signer, namely [Signing Profile]. This is a very simple resource type with effectively two properties, both of which, have been modeled according to the latest expectations of the CDK construct library. There is no good reason why this module ought to stay as experimental. Given the standard nature of this module, I do not expect much customer feedback on usability that would require backwards incompatible changes. Hence, marking this as stable. Motivation The `ISigner` interface is referenced by the `Function` construct in the `aws-lambda` module. This is an instance of a stable module depending on an experimental module. In CDKv2, we plan to ship only stable modules as part of the mono-release of the cdk (aka, `aws-cdk-lib`). A prerequisite to achieve this is to avoid such dependencies (stable → experimental). In this specific case, we are fixing this by promoting the `aws-signer` module to stable. [Signing Profile]: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-signer-signingprofile.html
CloudFormation supports only one resource type for AWS Signer, namely
Signing Profile.
This is a very simple resource type with effectively two properties,
both of which, have been modeled according to the latest expectations of
the CDK construct library.
There is no good reason why this module ought to stay as experimental.
Given the standard nature of this module, I do not expect much customer
feedback on usability that would require backwards incompatible changes.
Hence, marking this as stable.
Motivation
The
ISigner
interface is referenced by theFunction
construct in theaws-lambda
module. This is an instance of a stable module depending onan experimental module.
In CDKv2, we plan to ship only stable modules as part of the
mono-release of the cdk (aka,
aws-cdk-lib
). A prerequisite to achievethis is to avoid such dependencies (stable → experimental).
In this specific case, we are fixing this by promoting the
aws-signer
module to stable.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license