Skip to content

PLAY-21 Branch off 2.0 release

Raphael Mäder requested to merge PLAY-21 into master

Created by: ssokolenko

The release workflow with automated git tag based versioning scheme

The release workflow is set up in project/CmsRelease.scala using sbt-release and sbt-git plugins.

The project can be released by simply running the following command:

#!bash

sbt "release with-defaults"

which will do:

  1. Check for snapshot dependencies and aborting release if there are any. The snapshot dependencies are a moving target which must be avoided in the released projects. See the maven guide 7.2 The SNAPSHOT Qualifier to find out more about SNAPSHOTs.

  2. Inquire the release version. The release version is derived from the most recent git tag reachable from current commit and bumped up using maven versioning scheme, e.g. if the most reachable tag is "v2.0.0-SNAPSHOT" then:

  • the current released version will be "v2.0.0";
  • the next development version will be "v2.0.1-SNAPSHOT";
  • the next released version will be "v.2.0.1".

  1. Run "sbt clean"

  2. Run "sbt test"

  3. Set the release version. Update the runtime value of "version" setting on the project accordingly to inquired version in the 2nd step.

  4. Tag the release. Puts an annotated git tag on the released commit. The release will fail if the tag already exists, which means the project has already been released and there are no new commits to release.

  5. Run "sbt publish" Publish the artifacts to the configured maven/ivy repository. It may fail due to various reasons such as network connectivity issues or if there is already a package with the same version.

  6. Push a git tag to the remote origin. This step will require access to the remote repo.

Manually controlling the release version

It's possible to set the release version manually by running the release command without "with-defaults" parameter:

#!bash

sbt release

which will prompt for the release version. It will also prompt for the "next release version" which has no effect in current configuration and can be ignored.

Another way to affect the release version without manually running "sbt release" is to set up the corresponding git tag with "-SNAPSHOT" qualifier, e.g. if you're at "v2.0.9" and want to release the project with bumped up middle version "v.2.1.0" then the new git tag should be named "v.2.1.0-SNAPSHOT". It is recommended to create annotated git tags as they're automatically pulled and contain more contextual infos.

Merge request reports