---
title: Versioning
description: How we version Biome.
---

Fixes to lint rules, formatting layouts, etc. might prevent your scripts from passing. Due to the nature of these changes,
it's **highly recommended** to save the _exact_ version in your `package.json`, instead of using range operators.

This methodology will make sure that your script won't fail unexpectedly.

## Semantic Versioning

Biome follows [semantic versioning](https://semver.org/). Due to the nature of Biome as a toolchain, it can be unclear what changes are considered major, minor, or patch. That's why Biome uses the following versioning guide:

### Patch Release

* Fixing a lint rule that raises lint errors for valid code (false positives)
* Fixing incorrect code suggestions
* Fixing the formatting of a syntax that results in invalid code or changes the semantics of the program.
* Improvements to the documentation
* Internal changes that don't change Biome's functionality:
  * Refactors
  * Performance improvements
  * Increase or change in test coverage
* Improving the wording of diagnostics or fixing the rendering of diagnostics.
* Re-releases after a failed release
* Changing the formatting of established syntax.

### Minor Release

* Adding a new rule or promoting an existing lint rule to a stable group that is not recommended by default.
* Adding linting and formatting support for a recently introduced language feature, even if that results in more reported linting errors.
* Removal of recommended rules
* Deprecation of existing rules
* Adding new configuration optional configuration options that do not change the formatting or report more lint errors.
* Adding a new recommended lint rule or promoting an existing lint rule from the nursery group to a recommended lint rule in a stable group.
* Removal of a non-*nursery* rule or demoting a rule to the *nursery* group.

### Major Release
* Changes to the configuration that result in different formatting or more reported lint errors (adding/removing options, changing the default value)
* Changes to Biome's public API
* Promotion of new features or tools that require some spotlight

## Visual Studio Code Extension

Visual Studio Code [doesn't support pre-release tags](https://code.visualstudio.com/api/working-with-extensions/publishing-extension#prerelease-extensions) for extensions. That's why Biome uses the following version schema to distinguish stable and previews:
* Stable releases use even version numbers: 10, 12, 14, 16, ...
* Previews use odd version numbers: 11, 13, 15, 17, ...

## Why pinning the version is important

Pinning the version of Biome in your `package.json` is important to ensure that every team member and CI environments
use the same version of Biome. Even patch releases can result in slightly different formatting or linting results.