AWSX Breaking Change Evaluation
Use this skill to evaluate whether an AWSX change is compatibility-sensitive or
breaking for existing users.
This skill is for risk classification and required evidence. For component shape
guidance, use $awsx-component-design. For proof strategy, use
$awsx-test-authoring.
Rule Index
rules/public-schema-surface.md: schema and generated SDK public-surface
changes.rules/code-vs-behavior-breaks.md: code-level breaks versus preview/update
behavior changes.rules/child-identity-and-aliases.md: child logical names, parentage, URNs,
aliases, and migration paths.rules/defaults-and-supporting-resources.md: defaults, default-created
resources, tags, and supporting-resource changes.rules/provider-region-behavior.md: provider and region propagation changes.rules/upstream-inherited-breaks.md: changes inherited from @pulumi/aws or
AWS behavior versus AWSX-added breakage.
How To Use
- Identify the user-visible surface touched by the change: schema, generated
SDKs, child resource identity, defaults, providers/regions, or preview/update
behavior.
- Read the matching rule file.
- Classify the change as clearly safe, compatibility-sensitive, or breaking.
- If compatibility-sensitive, require evidence: schema comparison, generated
diff, mock test, provider-upgrade preview, targeted acceptance test, or an
explicit maintainer decision.
- Check the upgrade scenarios that match the change: existing user code still
compiles, existing stack preview is stable, child resource identity remains
compatible, and new programs get the intended behavior.
- Report the classification and evidence. Do not smooth uncertainty into a
confident answer.
Stop Early
Stop before approving compatibility if:
- existing user code might need to change;
- existing stacks might preview replacements, creates, deletes, or changed
inputs after upgrade;
- child names, parentage, aliases, provider tokens, module paths, defaults, or
output presence changed;
- the only evidence is that TypeScript compiles;
- the change is inherited from upstream but AWSX may be adding extra behavior on
top.
1---2name: awsx-breaking-change-evaluation3description: Tactical AWSX breaking-change evaluation guidance for pulumi-awsx. Use when assessing schema changes, generated SDK surface changes, child resource identity changes, aliases, changed defaults, provider or region behavior changes, and upgrade impact for existing users.4---56# AWSX Breaking Change Evaluation78Use this skill to evaluate whether an AWSX change is compatibility-sensitive or9breaking for existing users.1011This skill is for risk classification and required evidence. For component shape12guidance, use `$awsx-component-design`. For proof strategy, use13`$awsx-test-authoring`.1415## Rule Index1617- `rules/public-schema-surface.md`: schema and generated SDK public-surface18 changes.19- `rules/code-vs-behavior-breaks.md`: code-level breaks versus preview/update20 behavior changes.21- `rules/child-identity-and-aliases.md`: child logical names, parentage, URNs,22 aliases, and migration paths.23- `rules/defaults-and-supporting-resources.md`: defaults, default-created24 resources, tags, and supporting-resource changes.25- `rules/provider-region-behavior.md`: provider and region propagation changes.26- `rules/upstream-inherited-breaks.md`: changes inherited from `@pulumi/aws` or27 AWS behavior versus AWSX-added breakage.2829## How To Use30311. Identify the user-visible surface touched by the change: schema, generated32 SDKs, child resource identity, defaults, providers/regions, or preview/update33 behavior.342. Read the matching rule file.353. Classify the change as clearly safe, compatibility-sensitive, or breaking.364. If compatibility-sensitive, require evidence: schema comparison, generated37 diff, mock test, provider-upgrade preview, targeted acceptance test, or an38 explicit maintainer decision.395. Check the upgrade scenarios that match the change: existing user code still40 compiles, existing stack preview is stable, child resource identity remains41 compatible, and new programs get the intended behavior.426. Report the classification and evidence. Do not smooth uncertainty into a43 confident answer.4445## Stop Early4647Stop before approving compatibility if:4849- existing user code might need to change;50- existing stacks might preview replacements, creates, deletes, or changed51 inputs after upgrade;52- child names, parentage, aliases, provider tokens, module paths, defaults, or53 output presence changed;54- the only evidence is that TypeScript compiles;55- the change is inherited from upstream but AWSX may be adding extra behavior on56 top.
pulumi