skip to content

What does a -SNAPSHOT version mean in Maven, and how are SNAPSHOTs resolved and updated?

level: middleimportance: must knowfreq 65%

answer

  1. -SNAPSHOT = mutable, in-dev
  2. remote = timestamped+build-number
  3. maven-metadata.xml tracks latest
  4. updatePolicy default daily
  5. mvn -U forces refresh
  6. no SNAPSHOT in a release

basics

~20 s

A -SNAPSHOT version (e.g. 1.2.0-SNAPSHOT) marks an in-development, mutable version. On a remote repo each deploy is stored with a unique timestamp, and Maven re-checks for newer SNAPSHOTs periodically (by default daily). Release versions are immutable.

solid answer

~40 s

Appending -SNAPSHOT signals a version that is still changing. Unlike releases, SNAPSHOTs are mutable: the same logical version (1.2.0-SNAPSHOT) can be redeployed many times. On a remote repository each deploy is stored under a unique timestamped+build-number filename (e.g. myapp-1.2.0-20260621.101500-7.jar), and a maven-metadata.xml tracks the latest. Maven caches the resolved snapshot locally and only re-checks the remote on the configured updatePolicy — by default 'daily'. You can force a fresh check with `mvn -U` (update-snapshots). The semantics enable continuous integration: downstream projects depend on 1.2.0-SNAPSHOT and pick up new builds. Crucially, you must never release software that depends on a SNAPSHOT — the maven-release-plugin enforces this. Locally-built SNAPSHOTs go straight into ~/.m2 without timestamps.

code

bash · 4 lines
bash
# Force Maven to re-check remote repos for newer SNAPSHOTs
mvn -U clean install
# (equivalent long form)
mvn --update-snapshots clean install

go deeper

for a junior

Knows -SNAPSHOT means in-development/mutable and that release versions are fixed.

for a middle

Explains timestamped remote resolution, the daily updatePolicy, and mvn -U.

for a senior

Reasons about reproducibility risk and configures snapshot vs release repos and update policies for CI.

for a principal

Defines org policy on SNAPSHOT usage, retention/cleanup in the artifact repo, and reproducible-build guarantees for releases.

## Releases vs SNAPSHOTs Maven versions come in two flavors: - **Release** (e.g. `1.2.0`): **immutable**. Once deployed to a repository it must never change. Maven caches it forever and never re-checks. - **SNAPSHOT** (e.g. `1.2.0-SNAPSHOT`): **mutable**, in-development. The literal suffix is the uppercase token `-SNAPSHOT`. ## Timestamped resolution on remote repos When you `mvn deploy` a SNAPSHOT to a *remote* repository, Maven does NOT overwrite a single file. It stores each deployment under a **unique timestamped name**: ``` myapp-1.2.0-20260621.101500-7.jar ``` Here `20260621.101500` is the UTC timestamp and `7` is the build number. A `maven-metadata.xml` next to it records the latest timestamp/build so consumers know which one `1.2.0-SNAPSHOT` currently resolves to. This lets a repo keep history and lets multiple CI deploys coexist. ## Local repository behavior In your local `~/.m2/repository`, a SNAPSHOT you build yourself is just `myapp-1.2.0-SNAPSHOT.jar` (no timestamp) and is overwritten on each `mvn install`. ## Update policy / freshness Maven caches the resolved remote SNAPSHOT and only re-checks per the repository's **updatePolicy**: - `daily` (the **default**) — check at most once per day. - `always` — check every build. - `never` — never auto-check. - `interval:NN` — every NN minutes. ```xml <repository> <id>nexus-snapshots</id> <url>https://repo.example.com/snapshots</url> <snapshots> <enabled>true</enabled> <updatePolicy>always</updatePolicy> </snapshots> </repository> ``` Force an immediate refresh from the CLI with **`mvn -U`** (a.k.a. `--update-snapshots`). ## Rules and gotchas - A **released** artifact must not depend on any SNAPSHOT — builds become non-reproducible. The `maven-release-plugin` fails the release if it finds one. - SNAPSHOT repositories are usually configured separately from release repositories (`<snapshots><enabled>` toggles). - Because SNAPSHOTs change underneath you, two CI runs of the 'same' versions can produce different binaries — that's the trade-off for fast iteration. ## Mental model SNAPSHOT = 'work in progress, expect it to change'; release = 'frozen forever'.

  • Why are remote SNAPSHOTs stored with timestamps?
    To keep a history of each deploy and let multiple CI builds of the same logical version coexist; maven-metadata.xml records which timestamped build the SNAPSHOT currently resolves to.
  • How often does Maven re-check a remote SNAPSHOT by default, and how do you override it?
    Daily by default. Override per-repo with <updatePolicy> (always/never/interval:NN), or force a one-off refresh with mvn -U.
  • Can a 1.0.0 release depend on a 2.0.0-SNAPSHOT?
    It shouldn't — it makes the build non-reproducible. The maven-release-plugin will refuse to release with SNAPSHOT dependencies.

A SNAPSHOT is like a 'draft' Google Doc that keeps changing at the same URL; a release is a PDF you exported and froze.

saying these in an interview costs you the question

  • Saying SNAPSHOTs are immutable.
  • Claiming Maven always downloads the newest SNAPSHOT every build (default is daily).
  • Thinking local SNAPSHOTs get timestamps (only remote ones do).
  • Releasing artifacts that depend on SNAPSHOTs.

context

resolving links…