DPML
Version Builds
HomeUtilitiesStationMetroDepotTransit
Versioned Builds
Tutorial Objective

The objective of this tutorial is to demonstrate the usage of the -version option when building multiple projects.

Executing a versioned build

By default the build system assigns the version identifier of SNAPSHOT.

We can override this using the -version commandline option. In the following example we are requesting a listing of the in-scope projects together with the version cli option. The resulting list is the list of projects that would be build if we dropped to list option.

$ build -list -version ABC

Selection: [3]

  [1]   project:org/acme/plugin/clock-api#ABC
  [2]   project:org/acme/plugin/clock-impl#ABC
  [3]   module:org/acme/plugin#ABC

$
Adding a Decimal Prefix

A generalized version applies to a complete module is sometimes not sufficient to properly describe the desired results of a multi-p[roject build in terms of version naming requirements. For example, by applying the generic -version cli option we are stating that all resources defined withing the module (without an explicit version declaration) shall be produced with version XYZ. A more realistic scenario is that your top-level index versioning strategy could reflect a public XML specification whereas internal project version could reflect API based version evolution. In these scenarios it is useful to include a specification prefix - for example the version identifier "1.0.0-RC3" could be expressed as a decimal prefix of "1.0.0" and a version suffix of "RC3". Depot enables this strategy through the following properties:

project.version-prefix.enabled If true then the version value generated for a given project will be derived from the values of the major, minor and micro project version attributes described below.
project.major.version The major version prefix value (must be an integer).
project.minor.version The minor version prefix value (must be an integer).
project.micro.version The minor version prefix value (must be an integer). Typically used to represent a sequential publication value.

In version prefixing is enabled (typicically via a high-level module property defintion) and major, minor and micro versions are assigned within respective modules and projects (reflecting respective development lifecycles), then the resulting version assigned to a project artifacts will correspond to the the following convention:

[major].[minor].[micro]-[cli-supplied-version-argument]

The DPML project artifacts use the following convention:

major All resources sharing the same major version are deemed as backward compatible.
minor A minor version represents a functional extension or enhancement that is compatible within the context of the major version identifier.
micro A micro version represents a sequential release identifier relative to the [major].[minor] namespace.
Summary

The above sequence demonstrates the impact of the -version option in terms of resource naming and the corresponding meta-data (such as module information) that is generated by the build process. All of the resources (jars, module files, etc.) are now suitable for publication into a public (or shared) repository.