what are we going to promote to stable? enable-v12-overflowmenu, "OverflowMenuV2"
gather a list of all these, run a prioritization exercise with everyone, potentially use some of these attributes for signal:
How valuable is the change for consumers?
How valuable is the change for maintainers? (the Carbon team)
How disruptive is this change?
How much effort does the change require?
... each of the above attributes needs a scale defined - how do you define "low" disruption vs "high" disruption, for instance?
Design-focused items:
...
Solicit feedback on the plan via a playback of these findings and exercises to:
the greater Carbon team
the Carbon ecosystem - other internal/external framework authors, PAL library maintainers, strategic products, interested parties (previous "release partners"?)
Determine a plan for we intend to begin coordination of the v12 changeset with strategic library partners (@carbon/web-components, @carbon/ibm-products, carbon-components-angular, carbon-components-svelte) - ideally before the first prerelease?
Announce the plan
Could potentially coincide with #12494. The timelines match up for end of Q3 2024 or beginning of Q4 2024, which would also be 1 year from when we intend to ship the first v12 prerelease
Audit the v12 items to determine migration steps for each, if we should codemod, etc.
e.g. remove usages of light and replace by wrapping that component in a <Layer>
Determine if we want to continue with jscodeshift or use another tool within @carbon/upgrade
Determine what we want to include in v12 (to keep things
todo v12
,remove in v12?
, etc.)enable-v12-overflowmenu
, "OverflowMenuV2"Solicit feedback on the plan via a playback of these findings and exercises to:
@carbon/web-components
,@carbon/ibm-products
,carbon-components-angular
,carbon-components-svelte
) - ideally before the first prerelease?Announce the plan
Audit the v12 items to determine migration steps for each, if we should codemod, etc.
light
and replace by wrapping that component in a<Layer>
@carbon/upgrade