upgraded to gitversion 6

GitVersion.yml

@@ -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. 
+# 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
-# 
+# Package Naming:
+# - 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: []
-
-  
+  sha: []