fix(schema): unconfiguredBehavesLike contains info for multiple versions
#782
+75
−9
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…sions
The way it's currently specified, the `unconfiguredBehavesLike` field
that's in the Cloud Assembly Schema requires the CLI to know the current
major version of the CDK Library to properly evaluate:
It looks like `unconfiguredBehavesLike: { v1: ..., v2: ... }` subfields,
and that requires the CLI to know whether to look in the `v1` or `v2`
subfield (and in the future `v3`, `v4`, etc...).
That is unnecessary: since the CDK Library knows its own current version
so it could just have communicated `unconfiguredBehavesLike: true` to
accurately reflect its current behavior, without the consumer needing
to know anything about the version.
The CLI code right now is only reading the `v2` field, but that will
become inaccurate if we ever release CDKv3.
In this PR, we're saying that the `v2` subfield is the "official"
location of this value going forward. `v1` should be ignored if
present (but is still included to not trip up any JSON Schema
validation).
This leads to the least amount of interference with the existing ecosystem
(no forced upgrade by CDK users and no backwards compatibility path
in the CLI to potentially read 2 fields).
rix0rrr
requested a deployment
to
integ-approval
GitHub Actions
Waiting
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #782 +/- ##
=======================================
Coverage 80.81% 80.81%
=======================================
Files 63 63
Lines 8554 8554
Branches 1025 1026 +1
=======================================
Hits 6913 6913
+ Misses 1612 1611 -1
- Partials 29 30 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
otaviomacedo
approved these changes
Aug 11, 2025
rix0rrr
requested a deployment
to
integ-approval
GitHub Actions
Waiting
Signed-off-by: github-actions <[email protected]>
aws-cdk-automation
requested a deployment
to
integ-approval
GitHub Actions
Waiting
rix0rrr
added a commit
to aws/aws-cdk
that referenced
this pull request
Aug 12, 2025
…ry versions This change goes together with aws/aws-cdk-cli#782, to undo some decisions made in https://github.com/aws/aws-cdk/pull/35108/files and aws/aws-cdk-cli#742. We used to store `unconfiguredBehavesLike` values for both `v1` and `v2` (and `v3`, `v4`, etc) into the feature flag report, but we only needed to store the value for the *current* library version. We are now defining the "v2" field to hold the current version information, and are updating the feature flag generation code to not emit `v1` data, and stay correct if we ever start releasing `v3`.
mergify bot
pushed a commit
to aws/aws-cdk
that referenced
this pull request
Aug 12, 2025
…ry versions (#35215) This change goes together with aws/aws-cdk-cli#782, to undo some decisions made in https://github.com/aws/aws-cdk/pull/35108/files and aws/aws-cdk-cli#742. We used to store `unconfiguredBehavesLike` values for both `v1` and `v2` (and `v3`, `v4`, etc) into the feature flag report, but we only needed to store the value for the *current* library version. We are now defining the "v2" field to hold the current version information, and are updating the feature flag generation code to not emit `v1` data, and stay correct if we ever start releasing `v3`. This is labeled as a `chore` and not a `fix` because it doesn't really fix user-visible behavior. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
djglaser
pushed a commit
to djglaser/aws-cdk
that referenced
this pull request
Aug 13, 2025
…ry versions (aws#35215) This change goes together with aws/aws-cdk-cli#782, to undo some decisions made in https://github.com/aws/aws-cdk/pull/35108/files and aws/aws-cdk-cli#742. We used to store `unconfiguredBehavesLike` values for both `v1` and `v2` (and `v3`, `v4`, etc) into the feature flag report, but we only needed to store the value for the *current* library version. We are now defining the "v2" field to hold the current version information, and are updating the feature flag generation code to not emit `v1` data, and stay correct if we ever start releasing `v3`. This is labeled as a `chore` and not a `fix` because it doesn't really fix user-visible behavior. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The way it's currently specified, the
unconfiguredBehavesLikefield that's in the Cloud Assembly Schema requires the CLI to know the current major version of the CDK Library to properly evaluate:It looks like
unconfiguredBehavesLike: { v1: ..., v2: ... }subfields, and that requires the CLI to know whether to look in thev1orv2subfield (and in the futurev3,v4, etc...).That is unnecessary: since the CDK Library knows its own current version so it could just have communicated
unconfiguredBehavesLike: trueto accurately reflect its current behavior, without the consumer needing to know anything about the version.The CLI code right now is only reading the
v2field, but that will become inaccurate if we ever release CDKv3.In this PR, we're saying that the
v2subfield is the "official" location of this value going forward.v1should be ignored if present (but is still included to not trip up any JSON Schema validation).This leads to the least amount of interference with the existing ecosystem (no forced upgrade by CDK users and no backwards compatibility path in the CLI to potentially read 2 fields).
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license