I maintain a CSS framework that is versioning with semantic versioning.

What changes to a CSS framework are considered major, minor, and patches? Specifically, what is the "API" of a CSS framework? Is it simply the CSS classes available to you and how you use and combine them, or is it something more subjective like the way the framework looks and feels?

How might these definitions of major, minor, and patches be different between these different kinds of CSS frameworks:

  • What changes would you say "break" or change the implementation of the framework? For example removing a class thate breaks N hierarchical styles. Or dropping certain feature, as for example mobile-first or responsiveness. Or a whole revamp of the existing hierarchy of classes. If these changes result in web pages no longer lookng (maybe either working) as expected, then seems a reasonable major chnage
    – Laiv
    Aug 13 at 9:11

For me the definition of Major, Minor, Patch does not change when i apply it to different libraries / frameworks.

As a "user" of a library / framework, a "major" change is one, that may break my existing application.
For CSS that means, all changes that would remove or alter an existing styling would be "major". The part with "alter" is a bit hard, because a bugfix will very likely alter existing stylings.

A "Minor" change would be anything which can not break my application but provides additional features. For CSS that means adding additional classes, without altering existing ones.

And a "patch" change is exactly that, a bug fix. which should not add functionality and my application should behave exactly the same (minus the bug). That is something i think is hard in CSS, because if a library has a quirk which results in a visible symptom, it is very likely that people will create "workarounds". And then a bugfix has a good chance to "break" the styling, because of those workarounds.
Still it would be a bugfix change to me. Just that as a "user" i have to be aware that my own workarounds may now break the application.

Therefore i think "minor" is quite easy to define. The difference between a Major and a patch version is in CSS a bit harder, because in CSS most changes will affect somehow the application that uses the library / framework.

EDIT: As @Christophe mentioned, most changes will not "break" the application in the sense of throwing build or runtime errors. But by creating havoc with the styling.
In my personal definition, breaking the styling is a kind of "breaking the application".
If i use automated styling tests, which compare the rendered result against a prior result, those tests will fail. Aka the application is broken.
But this definition is debatable, i know. :-)

  • 1
    Indeed. The main difficulty is to define “major”, because even if all the css would be suppressed, it would not really break: the rendering would just be horrible. So defining what makes a change not acceptable as “backward compatible” would help to make an objective assessment
    – Christophe
    Aug 13 at 8:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.