skip to content

What is the difference between a SNAPSHOT version and a release version in Maven, and why does it matter for a release process?

level: juniorimportance: must knowfreq 75%

answer

  1. -SNAPSHOT = mutable
  2. timestamped on deploy
  3. updatePolicy / mvn -U
  4. release written once
  5. separate snapshot vs release repo

basics

~10 s

A SNAPSHOT (e.g. 1.0.0-SNAPSHOT) is a mutable in-development version that can change at any time; a release (e.g. 1.0.0) is immutable and published once. Releasing means dropping -SNAPSHOT and locking the artifact.

solid answer

~40 s

A version ending in -SNAPSHOT marks an artifact as under development. Maven treats SNAPSHOTs as mutable: it re-checks the remote snapshot repository on a configurable interval (updatePolicy) and downloads the newest timestamped build, so the same coordinates can resolve to different bytes over time. A release version (no -SNAPSHOT suffix) is meant to be deployed exactly once and is immutable — most repository managers (Nexus, Artifactory) reject redeploying the same release coordinates. This immutability is what makes release builds reproducible and safe to depend on. The release process converts X-SNAPSHOT to X, builds, tags, and deploys to a release repository, then bumps the working tree to the next -SNAPSHOT. SNAPSHOTs go to a separate snapshots repository.

code

bash · 2 lines
bash
# Force re-download of the newest SNAPSHOT instead of using the cached one
mvn -U clean verify

go deeper

for a junior

Knows -SNAPSHOT is in-development and removing it makes a release.

for a middle

Understands timestamped deploys, updatePolicy, and the two-repository routing in distributionManagement.

for a senior

Reasons about reproducibility risks of depending on SNAPSHOTs and enforces release immutability in CI/governance.

for a principal

Defines org-wide policy: snapshot retention, no-SNAPSHOT-in-release rules, repository layout, and reproducible-build guarantees.

## What a version is A Maven artifact is identified by GAV: groupId, artifactId, version. The version string carries special meaning when it ends in `-SNAPSHOT`. ## SNAPSHOT = mutable, in-development - `1.0.0-SNAPSHOT` means "the work-in-progress toward 1.0.0". - When deployed, Maven actually stores a **timestamped** filename like `myapp-1.0.0-20260621.103045-7.jar` in the remote repo, and `maven-metadata.xml` points to the latest. - On the consumer side Maven periodically re-resolves SNAPSHOTs according to the repository's `updatePolicy` (`daily` by default; also `always`, `never`, `interval:N`). Force a refresh with `mvn -U`. - Consequence: two builds on different days can pull **different bytes** for the same coordinates — convenient for sharing in-progress work, dangerous for reproducibility. ## Release = immutable, published once - `1.0.0` (no suffix) is a release. By convention and by repository-manager enforcement it is written **once** and never overwritten. - This is what lets you pin dependencies and get byte-for-byte reproducible builds. ## Why two repositories In `distributionManagement` you declare a `<repository>` (releases) and a `<snapshotRepository>` (snapshots). `mvn deploy` routes by whether the version ends in `-SNAPSHOT`. ```xml <distributionManagement> <repository> <id>releases</id> <url>https://nexus.example.com/repository/maven-releases/</url> </repository> <snapshotRepository> <id>snapshots</id> <url>https://nexus.example.com/repository/maven-snapshots/</url> </snapshotRepository> </distributionManagement> ``` ## Relevance to releasing The `maven-release-plugin` automates the transition: it strips `-SNAPSHOT`, builds + tags + deploys the release, then sets the next development version (e.g. `1.0.1-SNAPSHOT`). Understanding SNAPSHOT mutability explains why you must not ship a product depending on a SNAPSHOT.

  • How does Maven decide when to re-download a SNAPSHOT?
    By the repository's updatePolicy (daily by default); -U forces an immediate check. It compares maven-metadata.xml timestamps and pulls the newest timestamped build.
  • Why do repository managers reject redeploying a release?
    Releases are contractually immutable so consumers get reproducible, stable artifacts; allowing overwrite would silently change everyone's dependency.

SNAPSHOT is a Google Doc anyone can keep editing; a release is a printed, signed PDF — fixed forever.

saying these in an interview costs you the question

  • Saying SNAPSHOT just means "the latest version"
  • Claiming releases can be freely overwritten
  • Thinking SNAPSHOT and release share the same repository by default
  • Believing -SNAPSHOT is only a naming convention with no behavioral effect

context

resolving links…