skip to content

How do you version and release a BOM, and what SNAPSHOT pitfalls should you watch for?

level: seniorimportance: should knowfreq 35%

answer

  1. BOM version = version of the whole set
  2. SNAPSHOT = mutable, non-reproducible
  3. release plugin strips -SNAPSHOT
  4. no SNAPSHOTs in a released BOM
  5. flatten-maven-plugin for ${revision}

basics

~10 s

Version the BOM independently and bump it whenever the curated versions change. A BOM ending in -SNAPSHOT pins consumers to mutable versions, so consumers should import released (non-SNAPSHOT) BOM versions for reproducible builds.

solid answer

~40 s

A BOM has its own groupId/artifactId/version and is released like any artifact (e.g. via the maven-release/deploy plugins). Treat the BOM version as the version of the *whole curated set*: bumping it signals a coordinated change to the managed versions. SNAPSHOT pitfalls: if the BOM itself is `-SNAPSHOT`, importing it pulls the latest mutable build, so two consumers can resolve different versions over time — non-reproducible. Likewise, if the BOM *manages* SNAPSHOT versions of libraries, downstream builds inherit that mutability. For reproducible consumer builds, publish and import released BOM versions and avoid SNAPSHOTs in the managed entries. SNAPSHOTs are fine during internal integration but should not appear in a released BOM.

code

bash · 5 lines
bash
# Release a BOM (strips -SNAPSHOT, tags, bumps next dev version)
mvn release:prepare release:perform

# Or deploy a released version directly
mvn -Drevision=1.4.0 clean deploy

go deeper

for a junior

Know SNAPSHOT = changeable, release = fixed.

for a middle

Version the BOM independently; avoid SNAPSHOTs in released catalogs.

for a senior

Use release/flatten plugins; reason about reproducibility and override policy.

for a principal

Own release cadence and immutability guarantees for the org's BOMs.

## BOM versioning is set versioning A BOM's `<version>` represents the **version of the entire curated catalog**. When you change any managed version inside it, you publish a new BOM version. Consumers upgrade the whole set by bumping a single coordinate. This is exactly how `spring-boot-dependencies:3.3.0` works — one number, a whole tested matrix. ## Releasing a BOM A BOM is `packaging=pom`, so it is deployed as a `.pom` to your repository (Nexus/Artifactory/Central). You can: - Use the `maven-deploy-plugin` directly, or - Drive it with the `maven-release-plugin` (`release:prepare` / `release:perform`) which strips `-SNAPSHOT`, tags, and bumps to the next dev version. If the BOM lives in a multi-module reactor, the `flatten-maven-plugin` is often used so `${revision}`/`${project.version}` placeholders are resolved into a clean, consumable published POM. ## SNAPSHOT semantics refresher A version ending in **`-SNAPSHOT`** is *mutable*: the repository may serve a newer timestamped build each time, and Maven re-checks SNAPSHOTs per the repository's update policy. Released (non-SNAPSHOT) versions are **immutable** — once published they never change. ## Pitfall 1 — SNAPSHOT BOM ```xml <dependency> <groupId>com.acme</groupId> <artifactId>acme-bom</artifactId> <version>1.5.0-SNAPSHOT</version> <!-- mutable! --> <type>pom</type> <scope>import</scope> </dependency> ``` Two CI runs on different days can import different actual contents → **non-reproducible builds**. Fine for internal integration, dangerous for release. ## Pitfall 2 — SNAPSHOTs inside the BOM Even a released BOM is poisoned if it *manages* SNAPSHOT versions: ```xml <dependency> <groupId>com.acme</groupId> <artifactId>acme-core</artifactId> <version>1.5.0-SNAPSHOT</version> <!-- leaks mutability downstream --> </dependency> ``` The Maven release process refuses to release with SNAPSHOT dependencies for exactly this reason. ## Best practices - Released BOMs must contain only **released** versions. - Keep the BOM version meaningful and changelogged. - Let consumers override individual managed versions when needed (declare before the import) — but a clean BOM minimizes that need.

  • Why won't the maven-release-plugin release a project that has SNAPSHOT dependencies?
    Because SNAPSHOTs are mutable; a released artifact must be reproducible, so it would not be safe to depend on a moving target.
  • Is it ever OK to import a SNAPSHOT BOM?
    Only during internal development/integration. Never in a released build, because it makes resolution non-reproducible.

saying these in an interview costs you the question

  • Shipping a released BOM that manages -SNAPSHOT versions.
  • Treating SNAPSHOT versions as immutable.
  • Expecting two builds importing a SNAPSHOT BOM to resolve identical artifacts.

context

resolving links…