skip to content

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

level: middleimportance: must knowfreq 65%

answer

  1. prepare = strip, commit, tag, bump
  2. perform = checkout tag, deploy
  3. release.properties resumable
  4. needs <scm>
  5. rollback / clean

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.

solid answer

~40 s

The plugin runs a two-phase ceremony tied to your SCM. `release:prepare` verifies there are no SNAPSHOT dependencies and no uncommitted changes, sets the release version (drops `-SNAPSHOT`), updates the POMs, runs a test build, commits, creates an SCM tag, then sets the next development version (e.g. `1.0.1-SNAPSHOT`) and commits again. State is tracked in `release.properties` and `pom.xml.releaseBackup` so it is resumable. `release:perform` reads `release.properties`, does a fresh checkout of the tag into `target/checkout`, and runs the release goals (by default `deploy`, often with a `release` profile that also builds sources/javadoc and signs artifacts). The clean checkout guarantees the deployed artifact matches the tag exactly. `release:rollback` or `release:clean` undo or tidy a failed attempt. It requires `scm` configured in the POM.

code

bash · 4 lines
bash
mvn -B release:prepare release:perform \
  -DreleaseVersion=1.0.0 \
  -Dtag=v1.0.0 \
  -DdevelopmentVersion=1.0.1-SNAPSHOT

go deeper

for a junior

Knows the plugin tags and publishes a release without manual version edits.

for a middle

Can describe the prepare/perform split, the two commits, the tag, and release.properties.

for a senior

Drives it non-interactively in CI, handles rollback/recovery, and pairs it with a release profile for signing/sources/javadoc.

for a principal

Weighs it against modern alternatives (CI-friendly versions, jreleaser) and sets the org's release-engineering standard, including reproducibility and audit guarantees.

## Purpose The `maven-release-plugin` automates the repetitive, error-prone steps of cutting a release so the published artifact provably matches a tagged commit. ## Prerequisites - An `<scm>` section in the POM (connection, developerConnection, url). - A clean working tree and no `-SNAPSHOT` dependencies/plugins (prepare fails otherwise). - Credentials for the SCM and the deploy repository. ```xml <scm> <connection>scm:git:https://github.com/acme/app.git</connection> <developerConnection>scm:git:https://github.com/acme/app.git</developerConnection> <tag>HEAD</tag> </scm> ``` ## release:prepare (the local/SCM phase) 1. Checks for SNAPSHOT dependencies and uncommitted changes. 2. Prompts for (or takes) the release version, the SCM tag name, and the next development version. 3. Rewrites POM versions to the release version (removes `-SNAPSHOT`). 4. Runs `clean verify` to ensure it builds. 5. Commits the release POMs and creates the SCM **tag**. 6. Sets the next development version (e.g. `1.0.1-SNAPSHOT`) and commits again. - Progress is saved in `release.properties` (resumable) and POM backups. ## release:perform (the deploy phase) 1. Reads `release.properties`. 2. Performs a **fresh checkout of the tag** into `target/checkout`. 3. Runs the configured `goals` (default `deploy`) from that clean checkout, typically activating a `release-profile` that also attaches sources + javadoc jars and GPG-signs. ## Recovery goals - `release:rollback` — revert prepare's commits (before the tag is pushed/used). - `release:clean` — delete `release.properties` and backups. ## Non-interactive (CI) usage ```bash mvn -B release:prepare release:perform \ -DreleaseVersion=1.0.0 -Dtag=v1.0.0 -DdevelopmentVersion=1.0.1-SNAPSHOT ``` `-B` (batch mode) suppresses prompts. ## Why a clean checkout matters Deploying from the tag's fresh checkout (not your dirty working dir) guarantees byte-for-byte correspondence between the git tag and the published GAV.

  • Why does perform check out the tag instead of deploying from your working directory?
    To guarantee the deployed artifact corresponds exactly to the tagged commit, free of any uncommitted local changes.
  • What happens if a dependency is still a SNAPSHOT during prepare?
    prepare fails by default — you cannot release something that depends on mutable SNAPSHOTs, which would break reproducibility.
  • How do you recover from a failed prepare?
    Use release:rollback to revert the version-change commits, then release:clean to remove release.properties and POM backups before retrying.

saying these in an interview costs you the question

  • Saying it deploys directly from your local working tree
  • Forgetting it makes TWO commits (release + next dev)
  • Not knowing it requires an <scm> section
  • Claiming a single goal does everything (it's prepare then perform)

context

resolving links…