SNAPSHOT vs Release Versions in Maven
Fast recall
Quick revision
Core answer
-SNAPSHOT version identifies a changing development line, so a repository may publish newer timestamped builds under the same base version and Maven checks according to repository update policy. A release version such as 1.0.0 is expected to be immutable and is normally cached. Release naming improves repeatability, but it does not by itself guarantee byte-for-byte reproducible builds.Understanding Maven versioning semantics — SNAPSHOT behavior is a frequent source of confusion and build reproducibility issues
Not knowing that Maven re-downloads SNAPSHOTs periodically or that release versions are cached forever and never checked for updates
Mention that production deployments must never use SNAPSHOT dependencies because they're non-reproducible — today's 1.0.0-SNAPSHOT could be different code tomorrow
Interview-ready guide
Interview answer
A SNAPSHOT such as 1.0.0-SNAPSHOT is a moving development version. A repository may publish newer timestamped builds under that base version, and Maven checks for updates according to repository policy. A release such as 1.0.0 is expected to stay unchanged and is normally reused from the local repository.
For example, two developers resolving the same SNAPSHOT on different days may receive different builds. Releasing 1.0.0 removes that moving coordinate, but I would not call the build automatically reproducible: the JDK, plugins, environment, repository contents, generated timestamps, and other inputs also affect output. Teams usually keep SNAPSHOTs in development flows and deploy approved releases or immutable artifacts according to their release policy.
SNAPSHOT vs Release Versions in Maven
Direct Answer
A -SNAPSHOT version identifies a changing development line, so a repository may publish newer timestamped builds under the same base version and Maven checks according to repository update policy. A release version such as 1.0.0 is expected to be immutable and is normally cached. Release naming improves repeatability, but it does not by itself guarantee byte-for-byte reproducible builds.
Code Example
<!-- development build: re-fetched as it keeps changing -->
<version>1.0.0-SNAPSHOT</version>
<!-- release build: expected to remain immutable once published -->
<version>1.0.0</version>
mvn install -U forces Maven to re-download the latest SNAPSHOT instead of using the cached copy.
Common Mistakes & Pitfalls
- Deploying SNAPSHOT dependencies to production: Freshers sometimes ship applications that depend on SNAPSHOT versions, creating a nightmare scenario where production behavior changes unpredictably because Maven silently pulls a newer snapshot with breaking changes. production builds should normally use immutable release coordinates.
- Not understanding Maven's SNAPSHOT update policy: By default Maven checks for new SNAPSHOTs once per day, so freshers are confused when their build doesn't pick up the latest code their teammate just pushed. You need mvn clean install -U (uppercase U) to force an immediate update.
- Reusing release version numbers: After publishing 1.0.0 to Maven Central, freshers try to republish the same version with bug fixes. Maven Central rejects this because release versions are immutable. You must increment to 1.0.1 for any code change.
Check your understanding
Answer these without looking back at the article.
- How do you release a SNAPSHOT to a release version?
- What is the Maven Release Plugin?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.