How do we semver

[jimmynotjim]

While reviewing #697 I asked @Ans in passing if it should be a major change because it breaks the user's expected experience. We ended up entirely sidetracking the PR on an admittedly minor point. Rather than block that change and continue the discussion there, I am moving it here.

Because this project doesn't fit the typical semver example of an API, and the end user really is a site visitor, not just a developer, do we version based on the visitors' experience or the developers'?

Examples:

If we change how we build a component, but the rendered component is the same for the visitor, that could be a major or minor change for the developer but a patch from the visitor's perspective.

If we remove a component (even if that component wasn't widely used)t, like say the Hero, it's pretty clear that's a major change from both developers' and visitors' perspectives.

If we remove the webfont, that doesn't really affect developers in any way. The webfont was already being loaded without any work on their part. On the other hand it does affect visitors using one of the now unsupported browsers. Is that a major change? If not, is it a patch? It hasn't really affected the developer in any way, so it doesn't seem like a minor change from that perspective.

Current behavior

• Unclear how we semver

Expected behavior

• Document how we semver within the project and share it among the team.

Steps to replicate behavior

1. Think about minutiae far too much
2. Mention it in passing
3. Debate said minutiae 😜

[jimmynotjim]

This came up again as part of the svg icons work. We came across an issue we hadn't foreseen when we realized that the icons should be a minor update (added functionality, didn't deprecate anything) but the components that rely on cf-icons would need to be a major updated (without the updated cf-icons dependency, they would break). Our current thinking is to merge that PR into a v5 branch and release that on NPM as a prerelase. This would allow us to give it a month of testing before releasing it for real. The only issue would be that every time we release a patch or minor version of v4, we'd have to ensure that release was merged and released as a new pre-release on the v5 branch.

[Scotchester]

Hmm... @contolini and @wpears do you think that moving to fixed versioning effectively eliminates this problem?

[jimmynotjim]

FWIW, we're doing fixed versioning here and it really makes it easier to follow even if it means some packages get updated versions without any real changes. Still doesn't answer the point about who's perspective to use when deciding on a version level.

[anselmbradford]

This is handled by lerna according to @contolini