> ## Documentation Index
> Fetch the complete documentation index at: https://docs.parallaxprotocol.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Versioning

> What a major, minor, or patch release means, and which version to run

Parallax releases follow [Semantic Versioning](https://semver.org):
`MAJOR.MINOR.PATCH`, tagged as `vX.Y.Z`.

| Component       | Bumped for                                                                                                                                                                                                     | Example           |
| --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- |
| **PATCH** (`Z`) | Bug fixes, security patches, performance work. No new features and no interface changes — a drop-in upgrade.                                                                                                   | `2.0.0` → `2.0.1` |
| **MINOR** (`Y`) | Features added, changed, or removed: new RPC methods, new CLI flags, new subsystems. Node operators upgrade without changes; removals and behaviour changes are listed in the release notes.                   | `2.0.1` → `2.1.0` |
| **MAJOR** (`X`) | Breaking changes to the exported Go API — moved packages, renamed or removed types and functions. Code that imports Parallax as a library needs edits. `1.x` → `2.0` was the move to the layered architecture. | `2.1.0` → `3.0.0` |

The major digit tracks the **library** surface, so it matters most to developers
embedding the Go packages. For someone who only runs `parallaxd`, a major
release mostly means "read the release notes carefully."

## Which release to run

Run the latest patch release of the current stable series. Every release
carries a metadata tag alongside the version numbers:

| Metadata   | Meaning                                                                                                                                                              |
| ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `stable`   | A released build. The only kind recommended for mainnet.                                                                                                             |
| `rcN`      | Release candidate, e.g. `2.1.0-rc1`. Published for testing; any tag containing a hyphen is marked as a prerelease on GitHub and never moves the `latest` Docker tag. |
| `unstable` | A development build from the `main` branch, e.g. `2.1.0-unstable`. Not a release — the version names the *next* release, not the last one.                           |

Check what a node is running with:

```sh theme={null}
parallaxd version
```

Development and release-candidate builds also print the git commit and its date,
so any binary can be traced back to the exact source it was built from.

Binary downloads and Docker tags are described in
[Installing the client](../getting-started/installing-client).

## Release branches

Each minor series gets a long-lived branch, `X.Y.x` (for example `2.0.x`). The
series is cut when `X.Y.0` ships; patch releases are tagged from that branch,
while `main` moves on to the next minor's development cycle.

Documentation is versioned the same way — one folder per minor series — so the
docs for the release you are running stay available after newer ones land. Use
the version picker to switch.

## Importing Parallax as a Go library

The major version is part of the Go module path:

```go theme={null}
import "github.com/ParallaxProtocol/parallax/v2/kernel/chainparams"
```

```sh theme={null}
go get github.com/ParallaxProtocol/parallax/v2@latest
```

The `/vN` suffix is what lets a `3.x` release land without breaking code still
on `2.x` — Go treats the two as distinct modules that can coexist in one build.
The suffix was introduced in `v2.1.0`; earlier `2.0.x` tags are not resolvable
under the `/v2` path.

See the [Go API](../developers/dapp/go-api) page for the packages most
applications need.

## Consensus is not versioned by releases

The version number describes the *software*, never the *rules*. Parallax treats
consensus the way Bitcoin does: the rules are meant to stay fixed. There is no
scheduled fork cadence, and a new release is not an occasion to change how
blocks are validated. Client releases ship bug fixes, features, and refactors on
top of rules that are expected to outlive every version number in this scheme.

Consequently:

* A major version bump means the Go API moved, not that the chain changed.
  Upgrading from `2.x` to `3.x` does not imply a fork.
* On the rare occasion a consensus change is warranted, it activates at a **block
  height** rather than at a release boundary, and the release carrying it is
  mandatory for every node regardless of which digit moved.
* The wire protocols carry their own version numbers — `prl/66` for chain sync
  and `parallax-disc/1` for peer discovery — and bump independently of the
  release version.

Release notes state explicitly when an upgrade is mandatory rather than
optional.