Spring project versioning
Spring projects adhere to a strong set of rules for versioning artifacts. These are more that just 'best practices' or conventions because certain mechanisms such as the community download page depend on the naming and semantics detailed below. As detailed in sections below, the shared Gradle sources have expectations around versioning in order to determine (a) the build lifecycle, (b) where artifacts should be published, (c) whether maven central synchronization should occur, and more. Therefore it is imperative that these rules are followed.
{number}.{release_type}
where {number} is further broken down as {major}.{minor}.{micro}.
- 1.0.0.BUILD-SNAPSHOT
- 1.0.0.M1
- 1.0.0.M2
- 1.0.0.RC1
- 1.0.0.RC2
- 1.0.0.RELEASE
major/minor/micro semantics may have some variance across projects and this is fine.
In general:
- a major version suggests many significant new features, an associated marketing campaign, and possible breaking of backward compatibility.
- a minor version may also contain serious new features, but should not break compatibility. Spring Framework releases a minor version approximately once per year.
- a micro version typically contains many bug fixes and improvements and perhaps several smaller new features. Spring Framework releases a micro version approximately once every two months.
release-type semantics must not vary across projects
- BUILD-SNAPSHOT: A release currently in development. Such artifacts are typically produced by a nightly CI build, such as SPR-TRUNKSNAPSHOT or INT-NIGHTLY, and deployed to http://maven.springframework.org/snapshot.
- M#: A 'milestone' release. Such artifacts are usually produced manually, following the release process and are deployed to http://maven.springframework.org/milestone.
- RC#: A 'GA release candidate'. Such artifacts are produced with the exact same release process as milestones, and are also deployed to http://maven.springframework.org/milestone.
- RELEASE: A GA (Generally Available) release. Again, produced using the same release process. In this case, deployment happens (a) to http://maven.springframework.org/release and (b) to Maven Central.
Notice that the following sequence of versions is in ordered ascending both alphabetically and toward GA:
- 1.0.0.BUILD-SNAPSHOT
- 1.0.0.M1
- 1.0.0.RC1
- 1.0.0.RELEASE
This is intentional. In OSGi use cases, bundle versions have precedence based on their alphanumeric ordering. This explains, for instance, why Spring versions do not use Maven-conventional 1.0.0.SNAPSHOT naming. It would order alphanumerically after 1.0.0.RELEASE!
You will notice that build scripts using the shared Gradle sources typically contain
import org.springframework.build.Version
and
version = new Version(springIntegrationVersion)
This class encapsulates all necessary knowledge about the semantics of Spring project versions, and is used when:
- determining maven repository deployment URLs
- creating wildcard (1.0.x, 2.0.x) symlinks on the documentation server
- and more.
Take a look at this class and its tests for details.