Semantic Release

Tobias Schulte

Who am I?

The workflows

The workflows

Version in buildfile(s)

Developer triggers CI (optional parameters)

  • Build (check if it’s working)
  • Remove "-SNAPSHOT"
  • Commit and push
  • Create and push tag
  • Increase Version, append SNAPSHOT
  • Commit/Push
  • Checkout tag
  • Build version
  • Publish artefacts
  • Checkout branch head

⇒ Maven Release Plugin and some Gradle Plugins

Version in VCS

Developer triggers CI (optional parameters)

  • Build version
  • Create and push tag
  • Publish artefacts

⇒ the other Gradle Plugins

But first

What’s the new version?

Versioning Schemes

  • ${major}
  • ${major}.${minor}
  • ${major}.${minor}.${patch}
  • ${major}.${minor}.${patch}.${qualifier}
  • ${major}.${minor}.${patch}-RCx
  • ${major}.${minor}.${patch}-FINAL
  • TeX
  • Windows
  • …​

SemVer anyone?

MAJOR.MINOR.PATCH

Patch

Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior.
SemVer-specification

Minor

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API.
SemVer-specification

Minor

It MUST be incremented if any public API functionality is marked as deprecated.
SemVer-specification

Minor

It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.
SemVer-specification

Major

Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY include minor and patch level changes. Patch and minor version MUST be reset to 0 when major version is incremented.
SemVer-specification

SemVer anyone?

MAJOR.MINOR.PATCH

BREAKING.FEATURE.PATCH

0.x Versions?

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
SemVer-specification

Release notes anyone

noReleasenotes

Use Bugtracker

glazedlists automatic releasenotes

Use Commit message conventions …​

angular commit message convention

…​ to generate …​

angular commit message convention annotated

…​ the release notes

breaking patch version

Breaking changes sneaking in

breaking patch version annotated

Breaking changes sneaking in

glazedlists releasenotes

Breaking changes sneaking in

glazedlists releasenotes annotated

Breaking changes sneaking in

glazedlists upgrade instructions

Breaking changes sneaking in

glazedlists upgrade instructions annotated

Semantic Release

boennemann1

Hauptversionsnummernerhoehungsangst

Hauptversions-nummern-erhöhungsangst

Demo

Demo

Demo

How does it work

Version is inferred using the last tag (if any) and the commit messages

Only creates new version if any feature or fix commit

No tag yet ⇒ v1.0.0

Only fixes ⇒ increment PATCH

Any features ⇒ increment MINOR FEATURE

Any breaking features ⇒ increment MAJOR BREAKING

Default Branches

master

release/1.2.x

release/1.x

Remember this?

Developer triggers CI (optional parameters)

  • Build version
  • Create and push tag
  • Publish artefacts

Possible workflows

Work on master ⇒ every push triggers new version

Git-Flow, GitHub-Flow, etc. ⇒ merge to master (or release/1.x) triggers new version

(RCx-versions)

/