Versions

We’ll examine the convention followed for declaring versions of projects in this lesson and also the SNAPSHOT version.

Version

The version for a project should follow the below pattern:

<majorVersion>.<minorVersion>.<incrementalVersion>-<qualifier>

For instance, the project version 5.4.12 implies the major version is 5, minor is 4, incremental is 12, and that there is no qualifier. Similarly, the project version 2.5.1-alpha implies the major version is 2, minor 5, incremental 1, and that the qualifier is alpha. Finally, a project version 4 implies the major version is 4 and the rest are not defined. Following this format for defining project versions is helpful when defining project dependencies. We can define project dependencies as a range instead of a specific version. Maven will be able to determine the versions of a project that fall into a range if the above pattern of naming the project versions is followed. A range can be specified using the following:

1. (, ) exclusive quantifiers
2. [, ] inclusive quantifiers

For instance, if the version is specified as below:

<version>[3.8, 4.0)</version>

It implies that the dependency with a version of 3.8 or higher but less than 4.0 should be used. The lower boundary is inclusive, but the upper boundary is exclusive.

SNAPSHOT version

As a developer you’ll often come across artifact versions labelled as SNAPSHOT. A snapshot version signifies that the project is under active development and is treated slightly differently when deployed by Maven in a repository. The SNAPSHOT value refers to the latest code along a development branch and isn’t considered stable or unchanging. Consider a large organization that has several teams working on different parts of a product. If team A depends on a feature of team B’s actively developed artifact, then it will take a dependency on the SNAPSHOT version of the artifact. Team B will work on the feature and make daily releases as SNAPSHOT versions. Team B can’t make a regular release of the artifact as it is still being worked on, and team A must have access to the new code that is being created by members of team B. The solution for team B is to release code as a SNAPSHOT version to the organization’s internal repository. Maven always fetches the latest SNAPSHOT version from the remote repository for a SNAPSHOT dependency. This is in contrast to regular versions, whereby Maven looks up the dependency in the local repository; if found, an attempt to fetch the dependency from the remote repository is not made.

When uploading/deploying an artifact to a repository, if Maven encounters a version ending in “-SNAPSHOT”, it substitutes the token with a timestamp. The repository manager and client tools manage the translation from the snapshot version to the timestamped version. As a user, if you want to add a SNAPSHOT dependency, you’ll put in the version as “*-SNAPSHOT” and always get the latest version of the dependency. Here’s an example from the internet.

Notice that the version is set to “2.8.0-SNAPSHOT” and consists of jars with timestamps in their name. The idea is that you can continuously push the latest changes as a SNAPSHOT version and anyone depending on it gets the latest changes every time they build their project. Then, after a few iterations, when the code is stable enough, the latest SNAPSHOT version is permanently released as a regular version. In essence, the difference between a regular version and a SNAPSHOT version is that the SNAPSHOT version may get updates but the regular one will not. This implies, for instance, that downloading 1.0-SNAPSHOT of an artifact today might give a different file than downloading it yesterday or tomorrow. Finally, be cognizant that during the release process, a version of x.y-SNAPSHOT changes to x.y. The release process also increments the development version to x.(y+1)-SNAPSHOT. The snapshot precedes the actual release, it does not come after it. For instance, version 1.0-SNAPSHOT is released as version 1.0, and the new development version is version 1.1-SNAPSHOT.