mcoker
commented
5 months ago Notes from a discussion with @nicolethoen @srambach
The proposed plan is currently:
- Since we technically won't need a version in the token string until we need to implement a new version, we're going to hold off on adding a version for the time being, and when we need to add a new version, we'll start at v2
- Implied above with v2 and the issue description, but we confirmed the token version does not need to match the version of PF component classes/vars. Eg, maybe PF-v6/v7/v8 all use
--pf-t--globalif there are no breaking changes to tokens, and PF-v9 uses--pf-t--v2--global- Random related point, we're thinking that (for the most part) a breaking change to tokens will necessitate a breaking change to anything that consumes tokens, but breaking changes to things that consume tokens do not need to cause a breaking change in tokens or otherwise need to iterate/change token versions.
- Consider a unique version identifier in the string other than
v[n]for token versions, to make it clear it's not the same as or tied to a major version of PF. Eg, something like--pf-t-2--global - We can reconvene on the entire approach after v6/tokens release and we learn more about stuff like how they're used, what kinds of changes we're wanting to make to tokens,
We'll want to version the tokens for coordinating any breaking changes with core. Version will be a design-tokens version, not the core version. (However, we will have a mapping of what versions work together, e.g. design-tokens v1 works with core v6)