Skip to content

Git tag format

Jump to bottom
olf edited this page Mar 29, 2024 · 38 revisions

Summary

From 16 March 2023 on, for releases Git tags are used which must conform to releaseN_sfosX.Y[.Z]/<version>, with <version> being a semantic version the Version: tag is set to (i.e. content of %{version}), plus releaseN_sfosX.Y[.Z] set for the RPM Release: tag (i.e. content of %{release}) with N being a natural number ≥ 1. For example, release5_sfos4.2/0.3.1 is a valid release tag name, which results at the SailfishOS-OBS (build.sailfishos.org) in, e.g. harbour-storeman-0.3.1-1.13.1.jolla.armv7hl.rpm as the resulting RPM file name, with its spec file initially containing Version: 0.3.1 and Release: release5_sfos4.2, but the release string is overwritten later in the build process.

Similarly alpha, beta or release candidate (rc) versions are tagged as {alpha|beta|rc}N_sfosX.Y[.Z]/<version> (e.g. beta5_sfos4.2/0.3.0) and Release: set to {alpha|beta|rc}N_sfosX.Y[.Z], which results at Jolla's SailfishOS-OBS in, e.g. harbour-storeman-0.3.0-1.7.1.jolla.armv7hl.rpm.

Note that the Release: field must always be altered for GitHub (i.e. no two {alpha|beta|rc|release}N releases are allowed to exist for the same Version:) to achieve the correct order of releases, while the SailfishOS-OBS will do that automatically, but separately for each OBS repository!

sfosX.Y[.Z] denotes the branch in which the tag is set and {alpha|beta|rc|release} the expected status of the software. Hence other status identifiers such as adud may be used to not trigger a build at GitHub and specific SailfishOS-OBS repositories, if the corresponding CI workflows are configured correspondingly (as they should; currently also no status identifier at all (i.e. only sfosX.Y[.Z]/) triggers a CI run at GitHub). Mind the sorting: adud < alpha

Requirements

  • There must be an identifier in the tag names for releases which differentiates between the release branches, because Git tags are global for a Git repository, i.e. one cannot use the same tag name multiple times in different branches. Hence simply use the release branch name for that.
  • Have the regular %version from the spec file in the tag names, because that is how the RPMs built at GitHub are named.
  • [Non-requirement] It is very useful to also use %release in the Git tag names, but the classical use in the form of %version-%release does not work if both, SailfishOS-OBS and compiling using the unaltered spec file shall be supported. Hence the %release string is used as tag prefix as denoted above.

Analysis of tar_git

These sections were moved to a separate page, because they grew too long, despite being the principal reason for this "Git tag format" specification.

Clone this wiki locally