upgraded to gitversion 6

This commit is contained in:
Tig
2025-03-06 11:00:51 -07:00
parent adcc01ccee
commit e805023c1c
2 changed files with 60 additions and 67 deletions

View File

@@ -19,16 +19,14 @@ jobs:
fetch-depth: 0 # fetch-depth is needed for GitVersion
- name: Install GitVersion
uses: gittools/actions/gitversion/setup@v3
uses: gittools/actions/gitversion/setup@v3.1.11
with:
versionSpec: '5.x'
includePrerelease: true
versionSpec: '6.0.x'
- name: Determine Version
uses: gittools/actions/gitversion/execute@v3
uses: gittools/actions/gitversion/execute@v3.1.11
with:
useConfigFile: true
#additionalArguments: /b develop
updateProjectFiles: true
id: gitversion # step id used as reference for output values
- name: Setup dotnet
@@ -42,7 +40,6 @@ jobs:
- name: Build Release
run: |
dotnet-gitversion /updateprojectfiles
dotnet build Terminal.Gui/Terminal.Gui.csproj --no-incremental --nologo --force --configuration Release
dotnet test Terminal.Gui/Terminal.Gui.csproj --configuration Release

View File

@@ -1,92 +1,88 @@
# This file is used to configure GitVersion to work with the GitFlow branching strategy.
# This file configures GitVersion 6.x to work with Terminal.Gui's GitFlow branching strategy.
#
# Terminal.Gui uses the GitFlow branching strategy.
# https://gitversion.net/docs/learn/branching-strategies/gitflow/
#
# - We have two main branches: `v2_release` and `v2_develop`.
# - `v2_release` is the main branch for V2 releases and always matches the latest release package on Nuget (e.g. 2.0.0);
# prior to release it is a pre-release package (e.g. 2.0.0-prealpha.1).
# - `v2_develop` is the main branch for V2 development and is always a pre-release package (e.g. 2.0.0-develop.1).
# - We do all development work on feature branches off of `v2_develop`.
# - When we deem it time to do a release, we merge the feature branches into `v2_develop` and then `v2_develop` into `v2_release`.
# - The ./.github/workflows/publish.yml file is configured to build and publish on pushes to `v2_develop` and `v2_release`.
#
# We currently use GitVersion 5.1
# - `v2_release` is the main branch for V2 releases and matches the latest NuGet release package (e.g., 2.0.0);
# prior to release, it uses pre-release labels (e.g., 2.0.0-prealpha.1).
# - `v2_develop` is the development branch for V2 and always carries a pre-release label (e.g., 2.1.0-develop.1).
# - Development happens on feature branches off `v2_develop`.
# - For releases, we merge feature branches into `v2_develop`, then `v2_develop` into `v2_release`.
# - The ./.github/workflows/publish.yml builds and publishes on pushes to `v2_develop` and `v2_release`.
#
# Branches:
# - v1_release: This is `main` branch for V1
# - v1_develop: This is `develop` branch for V1
# - v2_release: This is `main` branch for V2
# - v2_develop: This is `develop` branch for V2
# - v1_release: Main branch for V1 (historical)
# - v1_develop: Develop branch for V1 (historical)
# - v2_release: Main branch for V2
# - v2_develop: Develop branch for V2
#
# Package Naming:
# - from v2_develop: v2.0.0-develop.1
# - from v2_release: Prior to Release: v2.0.0-beta.1 or v2.0.0-alpha.1 or v2.0.0-prealpha.1
# - from v2_release: Release: v2.0.0
# - from v2_develop: 2.1.0-develop.1 (minor version increments)
# - from v2_release (pre-release): 2.0.0-prealpha.1 or 2.0.0-beta.1
# - from v2_release (release): 2.0.0 (patch version increments)
#
mode: ContinuousDeployment # GitVersion 6.x uses Mainline mode for GitFlow, focusing on main branch releases
# We prefix our tags with a 'v' or 'V' (e.g. v1.0.0)
# We prefix our tags with 'v' or 'V' (e.g., v1.0.0)
tag-prefix: '[vV]'
# This is legacy from v1 and probably can be removed - see tag: develop below
continuous-delivery-fallback-tag: dev
branches:
# V2 Branches
# V2 Development Branch
develop:
# We don't really use ContinuousDeployment, but ContinuousDelivery - I don't remember why we have this here but it works.
mode: ContinuousDeployment
tag: develop
# Matches the v2_develop branch
regex: v2_develop
tracks-release-branches: true
is-source-branch-for: ['main']
# Adds 'develop' as pre-release label (e.g., 2.1.0-develop.1)
label: develop
# Increments minor version (x.y+1.z) on commits
increment: Minor
# No source branches specified as this is the root of development
source-branches: []
# Indicates this branch feeds into release branches
tracks-release-branches: true
# V2 Release Branch
main:
# We don't really use ContinuousDeployment, but ContinuousDelivery - I don't remember why we have this here but it works.
mode: ContinuousDeployment
# For V2 releases, prior to Alpha we use prealpha.
tag: prealpha
# Matches the v2_release branch
regex: v2_release
is-release-branch: true
# This tells GitVersion that the main (branch is the source branch for the develop branch.
# Uses 'prealpha' as pre-release label before official release
label: prealpha
# Increments patch version (x.y.z+1) on commits
increment: Patch
# Specifies v2_develop as the source branch
source-branches: ['develop']
# V1 Branches - These are really just here for reference.
# V1 Branches - Included for historical reference
v1_develop:
mode: ContinuousDeployment
tag: v1_develop
regex: v1_develop
source-branches:
- v1_release
label: v1_develop
increment: Minor
source-branches: ['v1_release']
# Lower weight keeps V1 pre-releases sorted below V2
pre-release-weight: 100
v1_release:
mode: ContinuousDeployment
regex: v1_release
is-release-branch: true
# Empty label for stable releases
label: ''
increment: Patch
source-branches: ['v1_develop']
# Pull Request Branches
# I don't fully understand this, but it seems to work
# Pull Request Branches
# Configures versioning for PRs (e.g., 2.0.0-pr.feature-123.1)
pull-request:
mode: ContinuousDeployment
tag: PullRequest.{BranchName}
increment: Inherit
tag-number-pattern: '[/-](?<number>\d+)'
# Matches typical PR branch names
regex: ^(pull|pull\-requests|pr)[/-]
# Uses 'pr' prefix with branch name in the label (e.g., pr.feature-123)
label: pr.{BranchName}
# Inherits increment strategy from source branch
increment: Inherit
source-branches:
- develop
- main
- feature
- support
- hotfix
- develop
- main
# High weight ensures PR versions sort after regular pre-releases
pre-release-weight: 30000
# I don't remember why we have this here but it works.
# Ignore specific commits if needed (currently empty)
ignore:
sha: []