SNAPSHOT and RELEASE versions: differences and appropriate use

WHAT THIS TESTS: This question probes whether you understand the Maven artifact lifecycle and the tension between development velocity and build reproducibility. Interviewers want to see that you know SNAPSHOT versions are mutable placeholders while RELEASE versions are immutable contracts, and that you can map each to the correct phase of a CI/CD pipeline.

A GOOD ANSWER COVERS: First, define mutability: a SNAPSHOT like 1.0-SNAPSHOT is a moving target that Maven can re-download on every build depending on the update policy, while a RELEASE like 1.0.0 is built once, tagged in version control, and never overwritten in the repository. Second, explain when to use each: SNAPSHOTs belong on feature branches and during local inter-module development where teams need rapid feedback without cutting formal releases; RELEASEs belong on the main branch and in production pipelines where every build must be bitwise reproducible. Third, mention tooling: mature teams use the Maven Enforcer Plugin with requireReleaseDeps to block SNAPSHOT dependencies in release builds, and they use mvn release:prepare and release:perform to automate version bumping, tagging, and deployment. Fourth, note repository isolation: SNAPSHOTs are typically deployed to a separate snapshots repository, while RELEASEs land in a releases repository with stricter permissions.

COMMON WRONG ANSWERS: Saying that SNAPSHOT and RELEASE are just naming conventions with no behavioral difference. Claiming that SNAPSHOT artifacts are safe for production because they are version controlled; the source may be tracked, but the resolved artifact can change underneath the build. Forgetting that Maven caches SNAPSHOTs locally and that builds can become non-deterministic if multiple developers publish different binaries under the same SNAPSHOT coordinate. Suggesting manual version editing instead of the release plugin, which invites human error.

LIKELY FOLLOW-UPS: How would you prevent a SNAPSHOT dependency from leaking into a production build? The interviewer expects mention of the Enforcer Plugin or CI gate checks. How do you handle versioning in a multi-module project? They want to hear about autoVersionSubmodules in the release plugin so all modules advance in lockstep. What update policy would you set for SNAPSHOTs in a CI environment? They are listening for interval-based or always policies on development branches and never on release branches.

ONE CONCRETE EXAMPLE: Imagine a team building a payment service that depends on an internal fraud-detection library. While adding a new risk rule, the fraud team publishes 2.5-SNAPSHOT to the shared repository. The payment service points to that SNAPSHOT on its feature branch so it can pick up daily improvements. Once the rule is finalized, the fraud team runs mvn release:prepare to create version 2.5.0, tags it, and deploys the immutable artifact. The payment service then updates its POM from 2.5-SNAPSHOT to 2.5.0 before merging to main, and a CI gate using the Maven Enforcer Plugin rejects any pull request that still references a SNAPSHOT.