skip to content

Explain SNAPSHOT versus release versions in Maven, including deploy and timestamping semantics.

level: seniorimportance: must knowfreq 75%

answer

  1. -SNAPSHOT = mutable, in-dev
  2. release = immutable, cached forever
  3. deploy appends timestamp+buildNumber
  4. updatePolicy daily; -U forces
  5. Nexus rejects release overwrite

basics

~20 s

A version ending in -SNAPSHOT is a mutable in-development version Maven re-checks for updates. A release version (no -SNAPSHOT) is immutable — once deployed it should never change. On deploy, snapshots get timestamped unique filenames; releases keep their plain version.

solid answer

~40 s

Versions ending in -SNAPSHOT (e.g. 1.4.0-SNAPSHOT) are treated as work-in-progress and mutable. When deployed to a repository, Maven appends a unique timestamp+build number to each snapshot upload (e.g. 1.4.0-20260621.101500-7.jar) and keeps a metadata file pointing to the latest, so consumers always pull the newest build. Maven also re-checks remote snapshots on a configurable updatePolicy (daily by default; force with -U). Release versions have no -SNAPSHOT, are immutable by convention, deploy with their literal version, and are cached forever locally once downloaded — never re-fetched. Most repository managers (Nexus/Artifactory) enforce this: snapshot repos allow redeploy, release repos reject overwriting an existing version. The maven-release-plugin automates stripping -SNAPSHOT for a release and bumping to the next -SNAPSHOT.

code

bash · 7 lines
bash
# Force re-download of the latest SNAPSHOT builds from remote
mvn -U clean install

# A deployed snapshot on the server looks like:
#   billing-1.4.0-20260621.101500-7.jar
# A deployed release looks like:
#   billing-1.4.0.jar

go deeper

for a junior

Know that -SNAPSHOT means in-development/changeable and a plain version is a stable release.

for a middle

Explain timestamped snapshot deploys, updatePolicy/daily re-checks, and the -U flag.

for a senior

Reason about reproducibility risks of SNAPSHOT dependencies and repository-manager enforcement of release immutability.

for a principal

Define org policy: no SNAPSHOTs in release builds, snapshot retention/cleanup, release automation, and CI cache strategy.

## Two kinds of versions Maven treats a version string specially based on whether it ends in **`-SNAPSHOT`**: - **Release version** — e.g. `1.4.0`. By convention **immutable**: once published, that exact version must never be changed. Once Maven downloads it, it caches it in `~/.m2` **forever** and never re-checks. - **Snapshot version** — e.g. `1.4.0-SNAPSHOT`. A **mutable, in-development** placeholder for "the next 1.4.0, not finished yet." Maven periodically re-fetches it. ## Snapshot timestamping on deploy When you `mvn deploy` a snapshot to a remote repository, Maven does **not** just overwrite a single file. It uploads a uniquely named copy with a UTC timestamp and incrementing build number: ``` billing-1.4.0-20260621.101500-7.jar ``` Alongside it, a `maven-metadata.xml` records the latest timestamp/buildNumber. So multiple snapshot builds coexist on the server, and consumers resolve the newest via the metadata. (In your **local** repo the snapshot is stored under the plain `-SNAPSHOT` filename.) Releases deploy with their literal name — `billing-1.4.0.jar` — and no timestamp. ## Update policy (re-checking) Because snapshots change, Maven re-checks remote snapshots on an **updatePolicy** configured per repository (`always`, `daily` (default), `interval:N`, `never`). Force an immediate re-check with: ```bash mvn -U clean install # -U / --update-snapshots ``` Releases are never re-checked once present locally. ## Repository manager enforcement Nexus/Artifactory split repos into **snapshot** and **release**: - Snapshot repos allow re-deploying the same version (overwrite/append). - Release repos **reject** redeploying an already-existing version, protecting immutability. ## Release automation ```bash # typical maven-release-plugin flow mvn release:prepare # strips -SNAPSHOT, tags SCM, bumps to next -SNAPSHOT mvn release:perform # builds & deploys the release version ``` ## Why it matters Depending on a `-SNAPSHOT` in a reproducible/CI build is risky: the bits can change under you between builds. Production builds should depend only on **release** versions for reproducibility.

  • Why is depending on a SNAPSHOT bad for reproducible builds?
    Snapshot contents can change between builds (the timestamped artifact behind 1.4.0-SNAPSHOT moves forward), so the same build run twice may produce different results. Releases are immutable, hence reproducible.
  • What does the -U flag do?
    It forces Maven to re-check remote repositories for updated SNAPSHOT artifacts and updated release metadata, bypassing the cached updatePolicy interval.
  • How are snapshots stored locally vs remotely?
    Remotely they get unique timestamp+buildNumber filenames with maven-metadata.xml tracking the latest; locally they're stored under the plain -SNAPSHOT name.

A SNAPSHOT is like a draft Google Doc that keeps changing; a release version is like a printed, signed PDF — once it exists, that exact copy is frozen.

saying these in an interview costs you the question

  • Saying release versions are re-downloaded periodically (they are cached forever)
  • Claiming SNAPSHOT and release behave identically on deploy
  • Thinking -SNAPSHOT can be overwritten on a release repository
  • Believing -U is needed for release dependencies

context

resolving links…