skip to content

Release & Version Plugins

2 roadmaps6 questions

The release plugin's prepare/perform tag-and-deploy sequence, bulk version edits with versions-maven-plugin, and CI-friendly ${revision} versioning. Interviewers ask because release automation is where the build meets git history.

on this pageshow

explore

questions

6

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…

open as a page

Walk me through what maven-release-plugin's release:prepare and release:perform actually do.

level: middleimportance: must knowfreq 65%

basics

~10 s

release:prepare strips -SNAPSHOT, commits, tags in SCM, then bumps to the next -SNAPSHOT and commits again. release:perform checks out that tag into a clean dir and runs deploy to publish the release artifacts.

open as a page

How do you use the versions-maven-plugin to manage dependency and project versions, and what does versions:set vs versions:use-latest-versions do?

level: middleimportance: should knowfreq 50%

basics

~10 s

versions-maven-plugin edits POM versions for you. versions:set changes the project's own version (across a multi-module build); versions:use-latest-versions bumps your declared dependencies to their newest available versions. It writes pom.xml.versionsBackup so you can revert.

open as a page

Explain Maven's CI-friendly versions using ${revision}, ${sha1}, and ${changelist}. Why are they used and what pitfall do they introduce?

level: seniorimportance: should knowfreq 45%

basics

~20 s

CI-friendly versions put a single version in one property (${revision}, plus optional ${sha1}/${changelist}) so you set it once, e.g. via -Drevision=1.2.3, instead of editing every module. The pitfall: the published POM still contains the literal ${revision}, so you must use flatten-maven-plugin to resolve it.

open as a page

What does flatten-maven-plugin do, and beyond CI-friendly versions, when else is a flattened POM valuable?

level: seniorimportance: nice to knowfreq 30%

basics

~10 s

flatten-maven-plugin generates a resolved, self-contained POM (.flattened-pom.xml) that is installed/deployed instead of the original. It inlines the parent, resolves properties like ${revision}, and can strip build-only sections so consumers get a clean, fully-resolved POM.

open as a page

Your team is moving releases into CI/CD. Would you keep maven-release-plugin or adopt CI-friendly versions with flatten + versions plugin? How do you decide?

level: principalimportance: nice to knowfreq 25%

basics

~20 s

It depends on who owns versioning and tagging. maven-release-plugin is SCM-driven and makes commits/tags itself; CI-friendly versions let the pipeline stamp the version (-Drevision) with flatten resolving the POM and the pipeline owning the git tag. For modern GitOps CI, the CI-friendly approach is usually cleaner.

open as a page