Versioning
FrontAlign follows Semantic Versioning (SemVer): every release is tagged MAJOR.MINOR.PATCH, and each segment tells you exactly what kind of change to expect before you touch your package.json.
1 . 1 . 0
│ │ │
│ │ └─ PATCH — bug fixes, no API or behavior changes
│ └───── MINOR — new features, fully backward-compatible
└───────── MAJOR — breaking changes to the public API
You can always upgrade across PATCH and MINOR releases without changing any of your code. MAJOR releases are the only ones that may require you to update your configuration, markup, or class names.
Version Scale
| Segment | Bumped when | Safe to auto-update? |
|---|---|---|
MAJOR | The public API changes in a way existing projects must react to | Review changelog first |
MINOR | A new utility, component, or token is added without touching existing ones | Yes |
PATCH | A bug is fixed or a token value is refined, no API surface changes | Yes |
Checking Your Installed Version
npx frontalign --version
The version is also always available in your project's package.json:
{
"dependencies": {
"frontalign": "^1.1.0"
}
}
The ^ range lets npm install pull any future MINOR or PATCH release automatically, while never crossing into a MAJOR version on its own.
What Counts as a Breaking Change
Not every visible change in the changelog triggers a MAJOR bump — only changes to the documented, public API do. Internal implementation details, even ones you could technically detect by inspecting the DOM or CSS, don't count.
For example, 1.1.0 standardized the internal "open" state class from .opened to .is-open across Dropdown, Collapse, Drawer, Accordion, Tooltip, Popover, and Modal. This shipped as a MINOR release, not a MAJOR one, because:
- The class is toggled internally by FrontAlign's JS, not something you're expected to set yourself.
- The documented configuration API (
data-*attributes) didn't change. - No HTML, attribute, or JS API changes were required on your end.
The only people affected are those who wrote custom CSS selecting .opened directly — the changelog calls this out explicitly so it isn't missed.
Reading the Changelog
Every release groups its entries under the same set of headings, so you can scan for what matters to you without reading line by line:
| Heading | Meaning |
|---|---|
| Added | New utilities, components, or tokens |
| Changed | Existing behavior or values were adjusted |
| Fixed | A bug was corrected |
| Improved | Internal tooling or build process refinements |
| Removed | A dependency, file, or feature was dropped |
The full history lives in CHANGELOG.MD at the root of the repository.
Current Release
| Version | Date | Highlights |
|---|---|---|
1.1.0 | 2026-07-24 | Nav vertical modifiers, a11y .sr-only utilities, print utilities, scroll-snap controls, focus-ring utilities |
1.0.6 | 2026-07-21 | Dark mode button hover tokens, Firefox text selection, RTL drawer fixes |
1.0.5 | 2026-07-16 | WCAG contrast pass on semantic colors |
1.1.0 is the current MINOR release on the 1.x line — every 1.0.x project can upgrade to it without any code changes.