What is a breaking change in Kaizen?

About

Developers should be aware of the definition of what a programmatic breaking change is defined by Semantic Versioning, that is:

Given a version number MAJOR.MINOR.PATCH, increment the:
    MAJOR version when you make incompatible API changes,
    MINOR version when you add functionality in a backwards compatible manner, and
    PATCH version when you make backwards compatible bug fixes.

This specification is not entirely descriptive of what is a breaking change in a Design System. We need to consider how visual changes to components cascade throughout the platform and be cognizant on the effect that has on components around it. Seemingly small changes can have a compounding effect on the platform and introduce visual defects.

As an example, if we were to bump the padding of tab items from 1.125rem to 1.5rem, some consumers of tabs may experience text wrapping: 1.125rem padding:

1.5rem padding:

I’d like to ask you all:

What do you consider to be a visual breaking change in Kaizen?

Resources

Visual Breaking Change in Design Systems - Nathan Curtis https://medium.com/eightshapes-llc/visual-breaking-change-in-design-systems-1e9109fac9c4

Versioning & Breaking Changes - Morningstar Design System https://designsystem.morningstar.com/getting-started/versioning-and-breaking-changes/

Versioning - Atlaskit https://atlaskit.atlassian.com/docs/guides/versioning

[ActuallyACat]

Also probably worth pointing out that “what is a visual breaking change in Kaizen?” is a separate question from “should a visual breaking change be represented by a major version bump?”.

Heavy plus one. I wonder if I was too ambitious with combining these two questions in the single issue, or whether that latter should be its own follow-up issue 🤔

If we could devise some sort of way of representing visual breaking changes as something parallel to semver I’d be all for it. It seems to me like we should just choose our own language come up with our own definitions and not worry about “standards” which seem ill-defined anyway.

I’m more interested in how we categorise the changes, rather than how to best enforce and represent them in changelogs (that sounds like a fun tooling and process challenge for later on!). What’s the impact of text wrapping vs changing colours that result in failing WCAG contrast? Are these two things equivalent in terms of impact, or is one of them “worse”? What other examples of visual defects can we surface?

One thing that gelled with me is Morningstar’s definition of breaking changes. It’s very clear about how it categorises changes to styles, fonts, icons and API and what to expect from major/feat/fix.

[mbylstra]

BTW, @ActuallyACat thanks for kicking off this discussion! 💯