What Is a Maven SNAPSHOT and Why Is It Used?

By the end of this page, you will understand what a Maven SNAPSHOT is, how Maven treats it differently from a release version, and why teams use snapshots while software is still changing. You will also see how snapshots appear in pom.xml, how dependency updates work, and when to use a snapshot versus a stable release.

In Maven, a SNAPSHOT is a development version of a project.

If a project version ends with -SNAPSHOT, it tells Maven:

• this version is still under active development
• it may change over time
• Maven may need to check for newer builds of the same version

For example:

<version>1.0-SNAPSHOT</version>

This does not mean a completely different version number each time. Instead, it means:

• the project is currently working toward version 1.0
• but that version is not final yet
• new builds can replace older snapshot builds

A release version is different:

<version>1.0</version>

A release is expected to be stable and permanent. Once published, it should not change.

Why snapshots matter

During development, teams often need to share unfinished work between modules or services.

Example:

• Team A is building a shared Java library
• Team B depends on that library
• Team A has not released 2.0 yet
• Team B still wants to test the latest in-progress changes

A snapshot solves this problem. Team A can publish 2.0-SNAPSHOT, and Team B can depend on it before the final release exists.

Think of a Maven SNAPSHOT like a draft document.

• A release version is like a signed final PDF: once sent, it should never change.
• A snapshot version is like a shared Google Doc draft: people can keep updating it while others review the latest state.

If your dependency is a release, you expect the exact same content every time.

If your dependency is a snapshot, you are saying: "Give me the current in-progress build of this version line."

That is why snapshots are useful in active development but risky for long-term stability.

The most common place you see a snapshot is in a Maven pom.xml file.

Declaring your project as a snapshot

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.example</groupId>
  <artifactId>demo-lib</artifactId>
  <version>1.0-SNAPSHOT</version>
</project>

This means your project is currently being developed toward version 1.0.

Using a snapshot dependency

<dependency>
  <groupId>com.example</groupId>
  <artifactId>demo-lib</artifactId>
  <version>1.0-SNAPSHOT</version>
</dependency>

Consider this dependency:

<dependency>
  <groupId>com.example</groupId>
  <artifactId>demo-lib</artifactId>
  <version>1.2-SNAPSHOT</version>
</dependency>

Now imagine the library team publishes snapshot builds during the day.

Step-by-step

1. The library project is marked as version 1.2-SNAPSHOT.
2. A developer runs a build and deploys it to the snapshot repository.
3. The repository stores it as a timestamped build, such as:
   • 1.2-20240610.090100-1
4. Your project depends on 1.2-SNAPSHOT.
5. Maven checks whether a newer snapshot is available, depending on update policy.
6. Later, the library team deploys another snapshot build:
   • 1.2-20240610.150500-2
7. On a future build, Maven may download the newer snapshot.
8. When development is complete, the team releases 1.2.
9. Projects should then move from 1.2-SNAPSHOT to .

Here are common situations where Maven snapshots are useful.

Shared internal libraries

A company has a common utility library used by several applications. While the library is still being updated, applications can depend on 3.0-SNAPSHOT and test the newest changes before the final release.

Multi-module development across teams

One team works on an API client, while another team builds a service that uses it. Snapshot versions allow both teams to integrate continuously instead of waiting for a formal release.

CI/CD pipelines for ongoing work

A continuous integration pipeline builds and publishes snapshot artifacts after each merge to a development branch. Other projects can test against the latest working build.

Testing breaking changes safely

Before releasing a major version, teams may publish a snapshot so consumers can try the new API and report issues early.

Plugin and framework development

When building a Maven plugin, Spring starter, or shared backend component, snapshots help downstream projects test in-progress functionality without requiring a final release every day.

In real projects, snapshots are usually part of a wider development workflow.

Common patterns

Internal dependency sharing

Teams publish snapshots to an internal artifact repository such as Nexus or Artifactory so other projects can consume the latest development build.

Early integration testing

A service may depend on payment-sdk:2.1-SNAPSHOT while the SDK team is still implementing a feature. This helps catch integration issues early.

CI-generated snapshot builds

A build server automatically deploys snapshot artifacts for non-release branches or the main development branch.

Guarding production stability

Many teams avoid snapshot dependencies in production builds because they want reproducible, stable deployments.

Release promotion workflow

A typical flow looks like this:

1. Develop with -SNAPSHOT
2. Test and stabilize
3. Release a fixed version like 2.1
4. Move next development cycle to 2.2-SNAPSHOT

Related development practices

• Validation: ensure dependencies point to approved repositories
• Early return mindset: stop a release build if any snapshot dependencies remain
• Configuration separation: allow snapshots in development environments but not in production
• Error handling: pin exact release versions when reproducibility matters

Beginners often misunderstand what snapshots are for.

Mistake 1: Treating a snapshot like a stable release

Broken assumption:

<version>1.0-SNAPSHOT</version>

A beginner may think this is fixed forever. It is not. New builds of the same snapshot can appear.

How to avoid it

Use a release version for stable builds:

<version>1.0</version>

Mistake 2: Using snapshots in production without care

If production depends on a snapshot, the build may behave differently later when a newer snapshot is downloaded.

How to avoid it

Prefer release versions for production deployments and reproducible builds.

Mistake 3: Forgetting repository settings

A snapshot dependency may fail if only release repositories are configured.

Broken example:

<repositories>
  <repository>
    <id>company-releases</id>
    <url>https://repo.example.com/releases
    
      true
    
    
      false
    
  

Snapshot vs local install

Quick reference

Snapshot version syntax

<version>1.0-SNAPSHOT</version>

Release version syntax

<version>1.0</version>

Key rules

• -SNAPSHOT means the version is still under development.
• Snapshot artifacts can be updated over time.
• Release artifacts should never change once published.
• Maven may resolve snapshots to timestamped builds in remote repositories.
• Snapshots are commonly stored in separate snapshot repositories.
• Releases are preferred for production and reproducible builds.

Typical workflow

1. Start development with 1.0-SNAPSHOT
2. Publish snapshot builds during development
3. Release final version as 1.0
4. Move next development cycle to 1.1-SNAPSHOT

Good practice

• Use snapshots for active collaboration
• Use releases for stable environments
• Avoid long-term production dependence on snapshots
• Make sure snapshot repositories are configured when needed

Common commands

What does SNAPSHOT mean in Maven?

It means the version is still being developed and is not a final release yet.

Why does Maven use snapshots?

Snapshots let teams share and test in-progress code without creating a new final version for every change.

Can a Maven snapshot change over time?

Yes. That is the main idea of a snapshot. New builds of the same snapshot version can replace older ones in repository resolution.

Is 1.0-SNAPSHOT the same as 1.0?

No. 1.0-SNAPSHOT is a development version. 1.0 is a final release version.

Should I use snapshot dependencies in production?

Usually no. Release versions are safer because they are stable and reproducible.

Why does Maven store timestamped snapshot files?

It helps repositories track the actual builds behind a logical snapshot version such as 1.0-SNAPSHOT.

What is the difference between mvn install and a snapshot deploy?

mvn install stores the artifact only on your local machine. A snapshot deploy publishes it to a shared repository for others to use.

• Maven coordinates — Group ID, artifact ID, and version are the identity of a Maven artifact.
• pom.xml — Snapshot and release versions are declared here.
• Maven repositories — Snapshots and releases are downloaded from or published to repositories.
• mvn install vs mvn deploy — Important for understanding local artifacts versus shared snapshot publishing.
• Artifact versioning — Snapshots are part of how Java projects manage evolving versions.
• Release management — Helps explain when a snapshot should become a final version.
• CI/CD pipelines — Snapshots are often created automatically in continuous integration workflows.