skip to content

Why does re-deploying the same release version usually fail, but re-deploying a SNAPSHOT succeeds? How would you design a release process around that?

level: seniorimportance: should knowfreq 40%

answer

  1. repo manager enforces release immutability
  2. release redeploy -> rejected (409)
  3. SNAPSHOT redeploy -> new timestamp
  4. fix release = new patch, never overwrite
  5. release:prepare blocks SNAPSHOT deps

basics

~20 s

Repository managers enforce release immutability: a release version can be published only once, so re-deploy is rejected. SNAPSHOTs are mutable, so each deploy adds a new timestamped build. To fix a release you publish a new version.

solid answer

~40 s

Release immutability is enforced by the repository manager (Nexus/Artifactory), not Maven itself: a hosted *release* repo rejects a second upload of the same GAV, guaranteeing `1.0.0` always means the same bytes. SNAPSHOT repos allow redeploy because SNAPSHOTs are mutable and each deploy is stored under a fresh timestamp/buildNumber. So a sound release process: develop on `x.y.z-SNAPSHOT`, and at release strip `-SNAPSHOT`, build/tag/deploy `x.y.z` once, then bump to the next `-SNAPSHOT`. The Maven Release Plugin (`release:prepare` + `release:perform`) automates this: it verifies no SNAPSHOT dependencies remain, sets the release version, tags SCM, deploys, then sets the next dev version. Hotfixes never overwrite — they ship as a new patch (`1.0.1`). This keeps builds reproducible and dependency graphs trustworthy.

code

bash · 4 lines
bash
# Automated release: verify no SNAPSHOT deps, tag, then deploy the release
mvn release:prepare
mvn release:perform
# Broken 1.1.0? Ship 1.1.1 -- never re-deploy 1.1.0

go deeper

for a junior

Knows you publish a release version once and bump for fixes.

for a middle

Explains the repo manager rejecting duplicate releases and SNAPSHOT redeploy creating new timestamps.

for a senior

Designs the SNAPSHOT->release->next-SNAPSHOT flow, uses the Release Plugin, and reasons about reproducibility/caching consequences.

for a principal

Sets org policy on immutability, yanking, version schemes, and automated release governance across teams and pipelines.

## The immutability rule A core Maven principle is that **a release version is immutable**: `com.acme:app:1.0.0` must always resolve to identical bytes for everyone, forever. This is what makes builds reproducible and dependency trees trustworthy. Who enforces it? The **repository manager**, not the Maven CLI. A *hosted release repository* in Nexus/Artifactory is configured to **reject** an upload whose GAV already exists, returning a 400/409. (The deploy plugin can also be told to fail.) SNAPSHOT-type repos are configured to **allow redeploy**, storing each upload under a new timestamp/buildNumber (see snapshot timestamping). ## Why SNAPSHOT redeploy is fine SNAPSHOTs are explicitly mutable: redeploying `1.0.0-SNAPSHOT` simply produces `1.0.0-<newTimestamp>-<N>`, and `maven-metadata.xml` advances to point at the newest. Consumers always get the latest. No corruption because each file is uniquely named. ## Designing the release process A clean lifecycle: 1. Develop on `1.1.0-SNAPSHOT`; deploy SNAPSHOTs freely (CI on every merge). 2. To release: remove `-SNAPSHOT` -> `1.1.0`; build once; deploy to the **release** repo; tag in SCM. 3. Bump POM to `1.2.0-SNAPSHOT` and continue. The **Maven Release Plugin** automates steps 2-3: ```bash mvn release:prepare # checks no SNAPSHOT deps, sets 1.1.0, commits, tags, sets 1.2.0-SNAPSHOT mvn release:perform # checks out the tag and runs deploy of the release ``` `release:prepare` **fails if any dependency or plugin is still a SNAPSHOT**, protecting reproducibility. ## Fixing a bad release You **never** overwrite `1.1.0`. If it's broken: - Publish `1.1.1` with the fix, or - Use the repo manager to *delete/yank* the bad version (rare, disruptive), then publish anew. ## Handling accidental redeploy needs If you truly must overwrite (a controlled internal repo), you would have to relax the repo policy — generally discouraged. The right answer in interviews is: **bump the version**. ## Trade-offs - Strict immutability = reproducibility but more version churn. - Allowing overwrite = convenience but breaks reproducibility and caching (consumers may have stale cached `1.1.0`).

  • If a consumer already cached a broken release 1.1.0, why can't you just overwrite it?
    Maven treats releases as immutable and won't re-download them, so consumers keep the stale cached copy. Overwriting also breaks reproducibility; the correct fix is a new version.
  • What does release:prepare check before releasing?
    That the working copy has no SNAPSHOT dependencies or plugins, that there are no uncommitted changes, then it sets the release version, commits, and tags SCM.
  • Who actually rejects the duplicate release upload?
    The repository manager (Nexus/Artifactory) via its hosted-release-repo policy, not the Maven client itself.

A release is like an ISBN on a published book — fixed forever; a correction means a new edition (new ISBN), not reprinting the same number with different text.

saying these in an interview costs you the question

  • Saying Maven core forbids release overwrite (it's the repo manager's policy).
  • Proposing to overwrite a released version to ship a fix.
  • Believing SNAPSHOT redeploy corrupts or overwrites the previous build.

context

resolving links…