|
12 | 12 | GIT_COMMAND="git -C $REPO_DIR" |
13 | 13 | origVersion="$VERSION" |
14 | 14 | rpmVersion="${VERSION#v}" |
15 | | -rpmRelease=3 |
16 | 15 |
|
17 | | -# rpmRelease versioning is as follows |
18 | | -# Docker 18.01.0-ce: version=18.01.0.ce, release=3 |
19 | | -# Docker 18.01.0-ce-tp1: version=18.01.0.ce, release=0.1.tp1 |
20 | | -# Docker 18.01.0-ce-beta1: version=18.01.0.ce, release=1.1.beta1 |
21 | | -# Docker 18.01.0-ce-rc1: version=18.01.0.ce, release=2.1.rc1 |
22 | | -# Docker 18.01.0-ce-cs1: version=18.01.0.ce.cs1, release=1 |
23 | | -# Docker 18.01.0-ce-cs1-rc1: version=18.01.0.ce.cs1, release=0.1.rc1 |
24 | | -# Docker 18.01.0-ce-dev nightly: version=18.01.0.ce, release=0.0.YYYYMMDD.HHMMSS.gitHASH |
| 16 | +# rpm "Release:" field ($rpmRelease) is used to set the "_release" macro, which |
| 17 | +# is an incremental number for builds of the same release (Version: / #rpmVersion). |
| 18 | +# |
| 19 | +# This field can be: |
| 20 | +# |
| 21 | +# - Version: 0 : Package was built, but no matching upstream release (e.g., can be used for "nightly" builds) |
| 22 | +# - Version: 1 : Package was built for an upstream (pre)release version |
| 23 | +# - Version: > 1 : Only to be used for packaging-only changes (new package built for a version for which a package was already built/released) |
| 24 | +# |
| 25 | +# For details, see the Fedora packaging guide: |
| 26 | +# https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_complex_versioning_with_a_reasonable_upstream |
| 27 | +# |
| 28 | +# Note that older versions of the rpm spec allowed more traditional information |
| 29 | +# in this field, which is still allowed, but considered deprecated; see |
| 30 | +# https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_complex_versioning_with_a_reasonable_upstream |
| 31 | +# |
| 32 | +# In our case, this means that all releases, except for "nightly" builds should |
| 33 | +# use "Version: 1". Only in an exceptional case, where we need to publish a new |
| 34 | +# package (build) for an existing release, "Version: 2" should be used; this script |
| 35 | +# does not currently account for that situation. |
| 36 | +# |
| 37 | +# Assuming all tagged version of rpmRelease correspond with an upstream release, |
| 38 | +# this means that versioning is as follows: |
| 39 | +# |
| 40 | +# Docker 22.06.0: version=22.06.0, release=1 |
| 41 | +# Docker 22.06.0-alpha.1: version=22.06.0, release=1 |
| 42 | +# Docker 22.06.0-beta.1: version=22.06.0, release=1 |
| 43 | +# Docker 22.06.0-rc.1: version=22.06.0, release=1 |
| 44 | +# Docker 22.06.0-dev: version=0.0.0~YYYYMMDDHHMMSS.gitHASH, release=0 |
| 45 | +rpmRelease=1 |
25 | 46 |
|
26 | | -if [[ "$rpmVersion" =~ .*-tp[.0-9]+$ ]]; then |
27 | | - testVersion=${rpmVersion#*-tp} |
28 | | - rpmVersion=${rpmVersion%-tp*} |
29 | | - rpmRelease="0.${testVersion##.}.tp${testVersion}" |
30 | | -elif [[ "$rpmVersion" =~ .*-beta[.0-9]+$ ]]; then |
31 | | - testVersion=${rpmVersion#*-beta} |
32 | | - rpmVersion=${rpmVersion%-beta*} |
33 | | - rpmRelease="1.${testVersion##.}.beta${testVersion}" |
34 | | -elif [[ "$rpmVersion" =~ .*-rc[.0-9]+$ ]]; then |
35 | | - testVersion=${rpmVersion#*-rc} |
36 | | - rpmVersion=${rpmVersion%-rc*} |
37 | | - rpmRelease="2.${testVersion##.}.rc${testVersion}" |
38 | | -fi |
| 47 | +# rpm packages require a tilde (~) instead of a hyphen (-) as separator between |
| 48 | +# the version # and pre-release suffixes, otherwise pre-releases are sorted AFTER |
| 49 | +# non-pre-release versions, which would prevent users from updating from a pre- |
| 50 | +# release version to the "ga" version. |
| 51 | +# |
| 52 | +# For details, see the Fedora packaging guide: |
| 53 | +# https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_handling_non_sorting_versions_with_tilde_dot_and_caret |
| 54 | +# |
| 55 | +# > The tilde symbol (‘~’) is used before a version component which must sort |
| 56 | +# > earlier than any non-tilde component. It is used for any pre-release versions |
| 57 | +# > which wouldn’t otherwise sort appropriately. |
| 58 | +# > |
| 59 | +# > For example, with upstream releases 0.4.0, 0.4.1, 0.5.0-rc1, 0.5.0-rc2, 0.5.0, |
| 60 | +# > the two "release candidates" should use 0.5.0~rc1 and 0.5.0~rc2 in the Version: |
| 61 | +# > field. Bugfix or "patchlevel" releases that some upstream make should be handled |
| 62 | +# > using simple versioning. The separator used by upstream may need to be replaced |
| 63 | +# > by a dot or dropped. |
| 64 | +# > |
| 65 | +# > For example, if the same upstream released 0.5.0-post1 as a bugfix version, |
| 66 | +# > this "post-release" should use 0.5.0.post1 in the Version: field. Note that |
| 67 | +# > 0.5.0.post1 sorts lower than both 0.5.1 and 0.5.0.1. |
| 68 | +# |
| 69 | +# The code below replaces hyphens with tildes. Note that an intermediate $tilde |
| 70 | +# variable is needed to make this work on all versions of Bash. In some versions |
| 71 | +# of Bash, the tilde would be substituted with $HOME (even when escaped (\~) or |
| 72 | +# quoted ('~'). |
| 73 | +tilde='~' |
| 74 | +rpmVersion="${rpmVersion//-/$tilde}" |
39 | 75 |
|
40 | 76 | DOCKER_GITCOMMIT=$($GIT_COMMAND rev-parse --short HEAD) |
41 | 77 | if [ -n "$($GIT_COMMAND status --porcelain --untracked-files=no)" ]; then |
|
0 commit comments