Skip to content

How to release FASTEN packages?

Jump to bottom
Sebastian Proksch edited this page Feb 27, 2022 · 1 revision

Our build workflows have been greatly simplified and now only consist of two main build steps:

  • Every push/PR triggers the verify workflow, which executes the Maven build (mvn clean verify) to check that the build runs through
  • Every tag using the format v1.2.3 will trigger the deploy workflow, which will version all packages and deploy them in the Maven and Docker registries of GitHub. (Please note: This workflow will be triggered irrespectively of the branch, so please be careful when tagging versions!)

Overall, creating a new release is very easy now and only requires following some simple steps:

  1. Develop your changes on a branch, every push will trigger the verify workflow.

  2. Open a PR to merge your changes. Merging an accepted PR into develop will trigger another run of the verify workflow.

  3. Whenever we want to release the current state of develop, please wait for all running verify actions on develop to complete successfully. Once this is the case, tag the latest commit on develop with the current stable version, i.e., when the current version in the code is 0.0.1-SNAPSHOT, use the tag v0.0.1. The build action will take care of replacing the version in the code with the release version. (Please note: tags contain an additional v in the version)

  4. Locally, run mvn versions:set -DnewVersion=$VERSION, where $VERSION is the next snapshot release. Concretely, if the tag was v0.0.1 set the version to 0.0.2-SNAPSHOT. (Please note: Maven versions do NOT include the v)

  5. Verify that only pom.xml files have been updated, commit the changes using the commit message Bump version to $VERSION. Depending on the repository, you can directly push this commit to the main branch (e.g., in the fasten repository), however, some repositories (like data-processing) do not allow direct pushes. In these cases either register yourself as a build maintainer, so you can bypass this check or temporarily disable it in the repo config. In any way, make sure that the version bump is the very first commit after the release.

  6. Make sure that you update all your other open branches/PRs to the new HEAD commit. This can be conveniently achieved through a rebase. If you prefer merging the main branch into your feature branch, please make sure that you are not accidentally reverting any version change.

If in doubt about any of these steps, please get in contact with Sebastian P. It is better to briefly clarify things, before messing-up the releases. :)

As a rule of thumb and to prevent a proliferation of releases, we should aim for a bi-weekly release cycle, e.g., after agreeing on the next release in our dev call.

Clone this wiki locally