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.

How Maven treats snapshots

Maven treats snapshots as mutable development artifacts.

That means Maven can periodically look for a newer build of the same snapshot version from a repository.

For example, these may all represent builds of 1.0-SNAPSHOT behind the scenes:

• 1.0-20240610.101500-1
• 1.0-20240610.143200-2

These timestamped files are generated in repositories, but developers usually keep writing 1.0-SNAPSHOT in pom.xml.

Release vs snapshot

A release version:

• is final
• should never change once published
• is used for stable production dependencies

A snapshot version:

• is still being worked on
• can be updated with newer builds
• is useful for testing ongoing changes across projects

Why we need snapshots

Snapshots help teams:

• integrate unfinished code early
• test changes across multiple modules
• avoid creating fake final releases too soon
• continuously share the latest build during development

Without snapshots, teams would either:

• constantly create many temporary release versions, or
• manually share JAR files, which is error-prone and hard to manage

So the core idea is simple: a Maven snapshot is Maven's way of saying, this version is not final yet, and it may be updated.

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>

This tells Maven to use the latest available build of 1.0-SNAPSHOT based on repository update rules.

Snapshot repository configuration

Many teams separate snapshot and release repositories.

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

Release example

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

This points to a fixed, stable version.

Beginner-friendly explanation

• Use 1.0-SNAPSHOT while building and testing unfinished work.
• Change it to 1.0 when that version is complete and ready to be permanent.
• Consumers of a snapshot may receive newer builds over time.
• Consumers of a release should always get the same artifact.

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 1.2.

What this means in practice

Although you wrote:

<version>1.2-SNAPSHOT</version>

Maven may internally resolve it to a specific timestamped snapshot artifact from the repository.

That lets developers keep using one readable version in pom.xml while the repository tracks the actual build history.

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

In mature codebases, snapshots are useful during active development, but releases are preferred for anything that must be stable and repeatable.

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</url>
    <releases>
      <enabled>true</enabled>
    </releases>
    <snapshots>
      <enabled>false</enabled>
    </snapshots>
  </repository>
</repositories>

How to avoid it

Add or enable a snapshot repository when needed.

Mistake 4: Never converting snapshots to releases

Some teams keep using -SNAPSHOT for too long, even after a version is stable.

How to avoid it

When a version is complete, publish a release and update consumers to that fixed version.

Mistake 5: Confusing local builds with published snapshots

Running mvn install puts an artifact in your local Maven repository. That helps on your machine, but it is not the same as publishing a snapshot for the whole team.

How to avoid it

Use mvn deploy to publish to a shared snapshot repository when other developers or CI systems need access.

Snapshot vs local install

When to use which

• Use a snapshot when the code is still changing.
• Use a release when the version is complete and should stay fixed.
• Use local install for personal development only.
• Use remote snapshot deployment for collaboration.

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

mvn install

Builds and installs to your local repository.

mvn deploy

Builds and publishes to a remote repository, often used for shared snapshots or releases.

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.