Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Versioning Scheme

DNS TAPIR Edge software uses semantic versioning for releases. The Edge components are released independently, but should all adhere to the same scheme, that is X.Y.Z. Development builds, nightly builds and other unofficial builds should have a version of 0.0.0.

Versioning Scheme for Debian-packaged Edge Components

Debian-packaged Edge software should adhere to the same scheme as the upstream component. That is, X.Y.Z for releases and 0.0.0 for unofficial packages. Additionally, for unofficial packages, a snapshot string will be used to identify when the build was made and what revision of the upstream code was used. For Edge components built from non-release revisions of the code, the versioning scheme will be 0.0.0+local20251118.<SHORT SHA>. Officially released packages will not have the snapshot part, i.e. it will just be X.Y.Z.

Versioning Scheme for RPM-packaged Edge Components

RPM-packaged Edge software follows similar rules as Debian-packaged software. The version format will be slightly different for unofficial builds: 0.0.0^20251118.<SHORT SHA>-1.

Embedding Versioning Information in an Executable Binary

All Edge binaries should have version and source code revision information stored in them. This can be done, for example by using the -ldflags option at build-time.

For example:

go build -ldflags "-X 'main.version=0.0.0' -X 'main.commit=12345678'"

This will create two variables with versioning information in main.go. Ideally, they should be printed when early on the binary is invoked. To make it clear when a binary has been built in a bad way, they can be declared like this in main.go:

# in main.go

var version = "BAD-VERSION"
var commit = "BAD-COMMIT"

When printed, it will be clear from the logs that the binary has not been built in the intended way and should be replaced.

Building In-repo vs. from Extracted Tarball

During development, one will typically build the binary by issuing make while standing in the root of a checked-out git repo. However, sometimes the binary will be built from an extracted tarball. In either case, versioning information should be embedded in the built binary. This means that the git sha and any tag information that is relevant must be included when making the tarball. For instance, it could be put into two files, VERSION and COMMIT, that are included in the tarball as it is created.