Skip to content

FAQ.md

Latest commit

 

History

History
89 lines (64 loc) · 4.3 KB

FAQ.md

File metadata and controls

89 lines (64 loc) · 4.3 KB
Raw

Frequently Asked Questions (FAQ)

Your Questions

Q: What are the different GitVersion modes?

A: GitVersion supports 3 versioning modes (set in gitversion.yml via mode: property). See GitVersion Modes Documentation:

Mode Purpose
Continuous Deployment (Current repo mode) Versions change with every commit. Assumes you deploy to production continuously. Perfect for fast-moving projects.
Continuous Delivery Versions keep changing but don't deploy as frequently. Useful for testing systems that aren't production.
Manual Deployment Stays on the same pre-release version until you explicitly deploy it. More controlled, less automatic. Traditional approach.

Your repo uses ContinuousDeployment to show clear version progression with each commit — great for demos.

Q: What is version-scheme: SemVer in gitversion.yml and why?

A: SemVer = Semantic Versioning — a standard for versioning with meaning: MAJOR.MINOR.PATCH (e.g., 1.2.3).

  • MAJOR bump (1.0.0 → 2.0.0) = Breaking changes
  • MINOR bump (1.0.0 → 1.1.0) = New features, backward compatible
  • PATCH bump (1.0.0 → 1.0.1) = Bug fixes

Your repo uses SemVer because it's industry standard, NuGet expects it, and developers understand it immediately. See Semantic Versioning spec for details.

Related settings in gitversion.yml:

  • semantic-version-format: Strict = Enforces proper SemVer format (1.2.3, 1.2.3-alpha.1)
  • semantic-version-format: Loose = More lenient, allows older formats like 1.2 (not recommended)
  • assembly-versioning-scheme: MajorMinor = Version in compiled assembly (1.2)
  • file-versioning-scheme: MajorMinorPatch = Version in file properties (1.2.3)

Adding New Questions

As you explore, new questions and answers will be added here!

Format:

### Q: [Your question]
A: [Answer]

Q: What happens if a developer creates a branch that doesn't match any pattern?

A: GitVersion has an "unknown" branch configuration that catches any unrecognized branch names. See GitVersion Configuration for details.

Example: If someone creates experiment or my-random-branch:

  • GitVersion recognizes it as "unknown"
  • Version becomes: 1.2.0-experiment.1 or 1.2.0-my-random-branch.1
  • It inherits versioning rules from the parent branch

Best practice: Encourage developers to follow your branch naming conventions (feature/, bugfix/, hotfix/, release/, etc.) for predictable versioning. This isn't required, but it keeps versions clean and meaningful.

Q: If I keep making commits to a branch, does the version change? Which number?

A: Yes, the version changes with each commit, but usually only the pre-release counter increments:

First commit:   1.2.0-prerelease.1
Second commit:  1.2.0-prerelease.2
Third commit:   1.2.0-prerelease.3

The 1.2.0 stays the same until you merge or release. The -prerelease.3 counter increments with each commit.

The increment setting (Minor, Patch) determines what WOULD bump if you released from this branch:

  • On feature/* branch: when released, becomes 1.2.0 (Minor bump)
  • On main branch: when released, becomes 1.0.1 (Patch bump)
  • On develop branch: when released, becomes 1.2.0 (Minor bump)

But while still on the branch making commits, only the pre-release counter changes, not Major/Minor/Patch.

Q: I'm converting an existing repo to GitVersion. My packages are already at v2.5.0. How do I tell GitVersion to start there?

A: Two approaches, but create a git tag (recommended):

Method 1: Git Tag (Permanent - Recommended)

git tag v2.5.0
git push origin v2.5.0

GitVersion uses this as the baseline. New commits become 2.5.1-prerelease.1, etc.

Method 2: next-version in gitversion.yml (Temporary) Add to gitversion.yml:

next-version: 2.5.0

⚠️ Per GitVersion docs, this is temporary only. Remove it once you've tagged properly. The docs advise: "If experiencing weird behavior, remove it and create a proper git tag instead."

Why git tags work best: Clean history, permanent, works across all machines/CI/CD, no ongoing config.