Tagged releases for Docker images
Certainly we have to provide distinct releases for Docker images in the mid-term.
This issue collects discussion and planning regarding releases of our Docker images as separately tagged images.
Technical
On a technical level, the most suitable approach for most repos is to lean into GitLab CI and Git tags to build and publish Docker images for releases.
A specific format of the tag (e.g. starting with v
followed by a number) would indicate to the CI pipeline that a release image should be published.
The Docker tag of the image would be based on the Git tag.
Open Questions
- How to handle releases for repositories with several images, most importantly this one? Tags with prefixes for the different images?
Release tag schemes
The (Docker) tags of releases should follow schemes yet to be decided. The scheme would depend on the kind of image, particularly what software is included, what interface is provided for consumption/use and what kind of releases make sense.
Some categories:
- (Base) images with none or one project-specific pieces of software (httpd, builder, scoreboard-tools, pytest?)
- Module images where source code is maintained
- Module images where source code is external (build scripts may be maintained or binaries may be downloaded directly)
- "Configuration" images which are not expected to be consumed, these can probably be omitted from release strategy
- Images meant for consumption (httpd-webdav, httpd-webdav-dockerfy) containing several pieces of software (httpd, modules, tools) and possibly configuration and configuration management utilities (particularly httpd-webdav-dockerfy).
Docker images are a complex form of packaging, containing core OS utilities (libraries, CLI tools, ...) as well as the entire dependency set of the primary content.
Some common schemes:
-
Semantic Versioning https://semver.org/lang/de/
The version scheme makes assurance regarding stability of the interface of the software. Upgrades to a new minor version do not break existing usage.
Appropriate when there is a clear interface (API, configuration file, ...). It may be extended with distribution versioning.
-
Distribution Versioning
Linux Distributions often extend the upstream release version of a package with a "revision" (names vary) so that several evolving package versions for a single upstream package can be released. This makes sense only if the distribution has minor impact on functionality, as a new distribution version should not break existing usage.
- https://www.debian.org/doc/debian-policy/ch-controlfields.html#version
- https://manpages.ubuntu.com/manpages/trusty/de/man5/deb-version.5.html
For our purposes, a revision part can also be added ad-hoc to the version if necessary.
-
Calendar Versioning https://calver.org/
The version is based on the release date of the package. This is useful to convey how much users are lagging behind the ever-evolving state of the included software.
Semantic information about interface stability may be contained by combining this with semantic versioning.
Reproducibility of image builds
Best case, each tagged release could be rebuild by re-executing the build pipeline at the Git tag. This would require fixing the version of all included software which is not realistic. However, the most crucial included software should have a fixed version.
/cc @Sven.Siebler