The general process is perhaps a little unconventional, we have three elements to consider.
- The backend / server code (Scala)
- The debian package available via
Each is managed separately but should be consistent in terms of the release artifacts.
To do this, we:
- Tag and release from the backend project using Github releases
build-webapp.sh), the UI project is not tagged or released via Github
- After tagging, immediately run
release-debian-package.shto publish the tagged version to the debian repository
The software is released using a major/minor number scheme with a Git SHA postfix. For example:
$ temperature-machine -- -v temperature-machine 2.1 (56add8)
SHA updates are generally used to get small increments out without the overhead of a “proper” release.
Tag and Release
To do release:
- draft a new release via the Github release page
- Tag the release consistently with the
- Ceate and deploy the Debian package (see below)
- Update the
build.sbt(don’t bother with a
SNAPSHOTpostfix, we use the SHA to discriminate)
NB. We could look into automating this with the
sbt-release plugin at some point. This would usually prepare a JAR, tag and copy the JAR to a local maven repo. We’re not interested in publishing the JAR via a Maven repository, instead we want to create a Debian package and publish that (so could delegate to our bash script from within a custom release “step”).
To create the Debian package and push it to the Robotooling repository, run the following: