Skip to content

Latest commit

 

History

History
55 lines (42 loc) · 2.28 KB

Release Procedure.md

File metadata and controls

55 lines (42 loc) · 2.28 KB

Release Procedure

Official Releases

Published Releases

Official listFix() releases can be found Github releases.

Versioning

Version policy iis strongly inspired on Semantic Versioning.

Given a version number MAJOR.MINOR.PATCH, increment the:

  1. MAJOR:
    • Drastic changes in the application
  2. MINOR:
    • Enhancements (new features) without breaking backward compatibility
  3. PATCH:
    • Bug fixes
    • Update software dependencies
    • Minor software improvements

Implementation

Versions are assigned using GitHub annotated tags, prefixed with a "v". So version 2.5.1 is tagged as v2.5.1. The "v" prefix helps to semantically distinct version tags from other tags. Using git describe the build process incorporates the build version into the application.

Building a release

./gradlew :clean
./gradlew :packageMyApp

Which will result in a corresponding .exe and .msi and which shall be attached to the GitHub release. The release will contain a changelog, which will be automatically drafted by the Release-Drafter bot, using rules defined in release-drafter.yml. These rules map Git labels assigned to Pull-Requests to following change categories:

  • 🚀 Enhancements
  • 🎨 Improvements
  • 🐛 Bug Fixes
  • 🔧 Under the hood

Some labels exclude the Pull-Request from the change-log, like:

These Pull-Request, did not change the distribution. internal maybe used to resolve an issue which has not been formally released.

Informal Releases

Informal releases may be found on Pull-Requests, with versions suffixed with a dask (-). E.g.: 2.5.1-16 or 2.5.1-[PR12]-16. The number is the commit distance to the last formal release, the PR annotation is added manually to the installer to identify the PR it belongs to.