S2 GA release plan and S1 future support plan

[GarthDB]

Problem statement

Spectrum 2 data will be published as Spectrum Tokens v13.0.0, as discussed in this other RFC. At that time, the data currently in the main branch, released as Spectrum Tokens v12.x.x, won't have any planned releases with feature updates. However, it is expected that some platforms, implementations, and products won't be able to switch over to Spectrum Tokens v13 immediately. This RFC is designed to discuss the plans for supporting S1 for those products after S2 graduates from beta.

History

Previous related RFCs:

• Spectrum, S2, S2-foundations updated merge plan
• Spectrum Tokens 12.x.x to Spectrum 2 migration proposal

Proposal

What will and won't be included in the S2 GA release?

Included:

• The current contents of beta branch

Not included:

• Composite tokens for drop shadows
• Adobe Clean VF and subsequent layout adjustments
• Updating dist directory format output
• Updating to Style Dictionary v4

These changes would result in breaking changes to the token output format and work to update the implementation parsers. It's planned to be completed using RFCs, snapshot/beta releases for partner vetting after S2 GA is released.

What types of changes should be expected, and who decides?

1. Typos, bugs, or small patches can be released without much coordination. The Spectrum Tooling Engineering Team can drive that work with minimal coordination with the Spectrum Design Team.
2. The Spectrum Design Team will coordinate/drive any other changes, but the Spectrum Tooling Engineering Team will most likely make the actual changes and releases from this repo.
3. No plans for new features for S1 once S2 is released to main/latest.
4. No architectural changes would be made to the S1 data, such as the JSON Schema.

How will releases be made?

We can keep an s1-legacy branch with the last of the S1 release's data that can be used for any releases needed. It would be expected to be released under the v12 version number.

Even if we don't have a branch with the s1 data, we can still checkout the git tag from the last v12.x.x release and provide the release that way.

Consequences or Required Actions

Any product still using an S1 version won't receive any new component or system features.

Unresolved questions

• If the Spectrum Design Team determines an S1 release is recommended, would they also update their design assets to match the design data updates?

Timeline

We'll keep this RFC open for comment until Monday, March 10, 2025.

We are planning to graduate from the beta branch to the main branch as described above on Thursday, March 13, 2025.

[jnjosh]

We can keep an s1-legacy branch with the last of the S1 release's data that can be used for any releases needed. It would be expected to be released under the v12 version number.

I know you say basically this in the next paragraph, so… Is this necessary to plan for? If there were an S1 update, couldn't we fork from the latest S1-based commit to a branch at that point, make the change and release it in the 12.x.x lifecycle?

[GarthDB]

Yes, but keeping a branch with S1 (even static) would enable the Figma Plugin and Tokens Studio integration to continue functioning with minimal impact.

[jnjosh]

Any product still using an S1 version won't receive any new component or system features.

I think you mean this but just to be clear with the previous section, we're saying there will be no new S1 components or features, but we reserve the right to do—however unlikely—minor updates to the system.

[rubencarvalho]

I agree this is a bit more nuanced - “new component or system features” would likely require net-new additions to tokens and I am OK with keeping these out of scope. However, we still need to support S1 through its deprecation/EOL stages, whether for bug fixes, accessibility improvements, or other minor updates. Could we reflect that?

[GarthDB]

The Spectrum Design Team owns and authors the data in Spectrum Tokens, so they will primarily drive any decisions regarding future releases in collaboration with engineering. A plan for deciding and communicating this is in the works.

Bug fixes, and minor updates won't be an issue regarding ease of updating and releasing. Accessibility improvements will likely depend on scope, scale, and timing.

[Deanna-w1]

+1 to what Garth mentioned. We decided that if changes are absolutely needed for S1 after the branch merges, we will either do a patch release at the Tokens level or fix it at the implementation or product level.

[allisonacs]

I know this is being captured elsewhere, but it might be worth saying here as well:

I personally anticipate there being very few if any patch releases necessary. Most of our accessibility "fixes" will be to direct teams to update to S2.

[GarthDB]

Thanks, @allisonacs!

[GarthDB]

Also, this change would impact the Spectrum Token Visualizer because it only shows the data in the main branch. A potential solution would be to create a second visualizer with the S1 archived data for those still using it.

[devongovett]

Not included:

Composite tokens for drop shadows
Adobe Clean VF and subsequent layout adjustments
Updating dist directory format output
Updating to Style Dictionary v4

Assuming this means you're planning a v14 for these changes?

[GarthDB]

Yes, those would likely all be considered breaking changes, so getting back to normal semver major releases.