MenuAPI/GitVersion.yml at fivem-enhanced · TomGrobbe/MenuAPI · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
# GitVersion configuration (FiveM Enhanced branch)
# Docs: https://gitversion.net/docs/reference/configuration
#
# Mode: Mainline — every commit to fivem-enhanced auto-increments the patch
# version, the same way the Legacy branch works. Override the increment for a
# specific commit by including one of these anywhere in the commit message:
#   +semver: major   →  bumps major (e.g. 1.2.3 → 2.0.0)
#   +semver: minor   →  bumps minor (e.g. 1.2.3 → 1.3.0)
#   +semver: patch   →  bumps patch (e.g. 1.2.3 → 1.2.4)  ← default
#   +semver: none    →  no bump on this commit
#
# Release tags are prefixed `enhanced-v` so they stay separate from the plain `v`
# tags on the Legacy branch. That prefix also stops GitVersion from reading the
# legacy versions as this line's own history.
#
# The Enhanced line shipped 0.1.0-alpha.1 through 0.1.0-alpha.22 while it was in
# development. It is stable now, so the alpha pre-release label is gone and builds
# are plain 1.0.0, 1.0.1, and so on.
#
# The jump from 0.1.0 to 1.0.0 is made by the `+semver: major` trailer on the commit
# that introduces this config, NOT by a next-version setting here. next-version acts
# as a floor rather than a starting point: with next-version 1.0.0 in place, the
# commit after tag enhanced-v1.0.0 still calculates as 1.0.0 and the version never
# moves again. The trailer only affects its own commit, so the series is free to
# carry on from the 1.0.0 tag by itself.

assembly-versioning-scheme: MajorMinorPatch
assembly-file-versioning-scheme: MajorMinorPatch
mode: Mainline
tag-prefix: 'enhanced-v'

branches:
  # Both release branch names match on purpose, even though this file is only ever read
  # from fivem-enhanced. The GitHub Actions runner tells GitVersion which branch it is on
  # through GITHUB_REF, and GitVersion trusts that over the branch actually checked out.
  # The combined pipeline checks out the OTHER branch to version it, so a run triggered
  # from legacy would otherwise find no matching entry here, fall back to the default
  # config and label the build 1.0.1-legacy.0. Matching both names makes the answer
  # depend on the repository being read rather than on which branch triggered the run.
  mainline:
    regex: '^(fivem-enhanced|legacy)$'
    increment: Patch
    is-mainline: true
    # An empty tag means no pre-release label, so builds are a plain 1.0.0 instead of
    # the old 1.0.0-alpha.N. GitVersion falls back to using the branch name as the
    # label for a branch it does not recognise, which would give 1.0.0-fivem-enhanced.1.
    tag: ''
    source-branches: []