skip to content

Can you publish SNAPSHOT versions to Maven Central? Explain SNAPSHOT vs release semantics in this context.

level: middleimportance: should knowfreq 40%

answer

  1. SNAPSHOT = mutable, in-dev
  2. Central = releases only, immutable
  3. separate snapshot repo, opt-in
  4. timestamped snapshot builds
  5. bump version, never re-release

basics

~10 s

No. Maven Central only accepts final release versions. SNAPSHOTs are mutable in-development versions and go to a separate snapshot repository, not Central. Released versions are immutable.

solid answer

~40 s

A `-SNAPSHOT` version (e.g. `1.2.0-SNAPSHOT`) is a *mutable, in-development* version: Maven treats it specially, re-checking the remote for newer timestamps and allowing overwrites. Maven Central holds only **immutable releases**, so SNAPSHOTs are rejected there. Sonatype provides a *separate* snapshot repository (under the Central Portal / OSSRH, e.g. `s01.oss.sonatype.org/content/repositories/snapshots` or the Central Portal snapshots endpoint) where SNAPSHOTs can be published and consumed by people who explicitly add it as a repository. Releasing means dropping the `-SNAPSHOT` suffix, producing signed artifacts with full metadata, and publishing the fixed version. Because Central releases are immutable, you can never re-release the same version — you bump to a new one. This is why release plugins (maven-release-plugin) automate the version-bump/tag/deploy dance.

code

xml · 7 lines
xml
<!-- Consuming snapshots requires opting in to the snapshot repo -->
<repository>
  <id>central-snapshots</id>
  <url>https://central.sonatype.com/repository/maven-snapshots/</url>
  <snapshots><enabled>true</enabled></snapshots>
  <releases><enabled>false</enabled></releases>
</repository>

go deeper

for a junior

Knows SNAPSHOT means in-development and that releases are final.

for a middle

Explains the separate snapshot repo, opt-in consumption, and immutability of releases.

for a senior

Uses maven-release-plugin and reasons about reproducibility/caching implications.

for a principal

Defines versioning/release cadence policy and snapshot-repo access governance.

## SNAPSHOT vs release A Maven version ending in **`-SNAPSHOT`** signals "work in progress." Maven gives it special treatment: - It periodically re-checks the remote repository for a newer build (controlled by `<updatePolicy>`). - Each deploy can produce a **timestamped** artifact (e.g. `widget-1.2.0-20260101.120000-3.jar`) but resolves under the `-SNAPSHOT` alias, so it is effectively **mutable** — "latest snapshot" changes over time. A **release** version has no `-SNAPSHOT` suffix and is **immutable**: once published it never changes. ## Why Central rejects SNAPSHOTs Maven Central is a permanent, cached-by-mirrors public corpus. Mutable artifacts would break reproducibility and caching. So **Central accepts only releases.** Trying to deploy a `-SNAPSHOT` to the release endpoint fails validation. ## Where SNAPSHOTs go Sonatype runs a **separate snapshot repository**. Consumers must explicitly opt in: ```xml <repositories> <repository> <id>central-snapshots</id> <url>https://central.sonatype.com/repository/maven-snapshots/</url> <snapshots><enabled>true</enabled></snapshots> <releases><enabled>false</enabled></releases> </repository> </repositories> ``` (Historically OSSRH used `https://s01.oss.sonatype.org/content/repositories/snapshots`.) ## Releasing 1. Drop `-SNAPSHOT` → `1.2.0`. 2. Build signed artifacts (jar, sources, javadoc, pom + `.asc`). 3. Deploy/publish; Central validates and releases (immutable). 4. Bump to the next dev version `1.2.1-SNAPSHOT`. The **maven-release-plugin** automates this: `release:prepare` (set release version, tag, set next dev version) and `release:perform` (checkout the tag and `deploy`). ## Immutability consequence If `1.2.0` has a bug, you cannot replace it — release `1.2.1`. This is a frequent interview gotcha.

  • What happens if you try to deploy a -SNAPSHOT to the Central release endpoint?
    It is rejected — Central accepts only immutable release versions; SNAPSHOTs must go to the separate snapshot repository.
  • How do consumers get a SNAPSHOT dependency?
    They must explicitly add the snapshot repository with <snapshots><enabled>true</enabled></snapshots>; it is not resolved from Central by default.

SNAPSHOT is like a draft document you keep editing in place; a release is a printed, archived edition you can't take back — you publish a new edition instead.

saying these in an interview costs you the question

  • Claiming you can publish SNAPSHOTs to Central proper
  • Thinking a released version can be edited if you redeploy
  • Believing snapshots are resolved from Central by default

context

resolving links…