build/version-at-commit.sh

   1 #!/bin/bash
   2 # Copyright (C) The Arvados Authors. All rights reserved.
   3 #
   4 # SPDX-License-Identifier: AGPL-3.0
   5
   6 set -e -o pipefail
   7 commit="$1"
   8 devsuffix="~dev"
   9
  10 # automatically assign *development* version
  11 #
  12 # handles the following cases:
  13 #
  14 # *  commit is on main or a development branch, the nearest tag is older
  15 #    than commit where this branch joins main.
  16 #    -> take greatest version tag in repo X.Y.Z and assign X.(Y+1).0
  17 #
  18 # *  commit is on a release branch, the nearest tag is newer
  19 #    than the commit where this branch joins main.
  20 #    -> take nearest tag X.Y.Z and assign X.Y.(Z+1)
  21
  22 # X.Y.Z releases where Z=0 are called major
  23 # releases and X.Y.Z releases where Z>1 are called point releases.
  24 #
  25 # The development process distinction is that X.Y.0 releases are
  26 # branched from main and then subsequent X.Y.Z releases cherry-pick
  27 # individual features from main onto the "X.Y-staging" branch.
  28 #
  29 # In semantic versioning terminology an "X.Y.0" release which only
  30 # increments Y is called a "minor" release but typically these
  31 # releases have significant changes that calling them "minor" in
  32 # communications with users feels misleading.
  33 #
  34 # Incrementing X is reserved for times when a release has significant
  35 # backwards-incompatible changes, which we don't do very often and try
  36 # to avoid.
  37 #
  38 # In order to assign a useful development version, we need to
  39 # determine if we're on the main branch (or a development branch off
  40 # main) or on a release branch.  We do this by looking at the point
  41 # where the current commit history branched from main.
  42 #
  43 # If a new major version appeared on a branch (not directly in the
  44 # history of main), the merge-base between main and the release should
  45 # be tagged as "development-X.Y.Z" so that version-at-commit can
  46 # figure out what to do.
  47
  48 # 1. get the nearest tag with 'git describe'
  49 # 2. get the merge base between this commit and main
  50 # 3. if the tag is an ancestor of the merge base,
  51 #    (tag is older than merge base) increment minor version
  52 #    else, tag is newer than merge base, so increment point version
  53
  54 nearest_tag=$(git describe --abbrev=0 "$commit")
  55 merge_base=$(git merge-base origin/main "$commit")
  56
  57 if git merge-base --is-ancestor "$nearest_tag" "$merge_base" ; then
  58     # the nearest tag appears before the merge base with main (the
  59     # branch point), so assume this is a tag for the previous major
  60     # release (or a tag with the "development-" prefix indicating the
  61     # point where a major release branched off).  Subsequent
  62     # development versions are given the anticipated version for the
  63     # next major release.
  64     #
  65     # x.(y+1).0~devTIMESTAMP, where x.y.z is the newest version that does not contain $commit
  66     # grep reads the list of tags (-f) that contain $commit and filters them out (-v)
  67     # this prevents a newer tag from retroactively changing the versions of everything before it
  68     v=$(git tag | grep -vFf <(git tag --contains "$merge_base") | sort -Vr | head -n1 | perl -pe 's/(\d+)\.(\d+)\.\d+.*/"$1.".($2+1).".0"/e')
  69 else
  70     # the nearest tag comes after the merge base with main (the branch
  71     # point).  Assume this means this is a point release branch,
  72     # following a major release.
  73     #
  74     # x.y.(z+1)~devTIMESTAMP, where x.y.z is the latest released ancestor of $commit
  75     v=$(echo $nearest_tag | perl -pe 's/(\d+)$/$1+1/e')
  76 fi
  77
  78 # strip the "development-" prefix
  79 v=$(echo $v | perl -pe 's/^development-//')
  80
  81 isodate=$(TZ=UTC git log -n1 --format=%cd --date=iso "$commit")
  82 ts=$(TZ=UTC date --date="$isodate" "+%Y%m%d%H%M%S")
  83 echo "${v}${devsuffix}${ts}"