Back to Terminal Gui

Terminal.Gui Library — Maintainer Guide

Terminal.Gui/README.md

2.0.17.8 KB
Original Source

Terminal.Gui Library — Maintainer Guide

This directory contains the core Terminal.Gui library source code. This README documents how to maintain and release the library. For contribution guidelines, see CONTRIBUTING.md. For building apps with Terminal.Gui, see the documentation.

Versioning

Versions are computed automatically by GitVersion 6.x using the GitFlow branching strategy. Configuration is in GitVersion.yml.

The GitVersion.MsBuild NuGet package is included in Terminal.Gui.csproj and automatically sets Version, AssemblyVersion, FileVersion, and InformationalVersion from git history at build time. No manual version management is needed.

How Versions Are Computed

BranchExample VersionIncrementNotes
main (stable)2.0.0PatchLabel set in GitVersion.yml (label: '')
main (pre-release)2.0.1-rc.1PatchLabel set in GitVersion.yml (e.g., label: rc)
develop2.1.0-develop.42MinorAlways carries -develop pre-release label
feature/*, fix/*, etc.2.1.0-my-feature.1InheritInherits from develop; branch name becomes label
pull-request/*2.0.0-pr.123.1InheritPR number in label

Checking Versions Locally

powershell
# Install the CLI tool (one-time)
dotnet tool install --global GitVersion.Tool

# Show what version would be computed for the current branch
dotnet-gitversion

The version is also embedded in every build. For example, UICatalog --version displays the terse SemVer (build metadata after + is stripped).

Pre-Release Label Progression on main

To change the pre-release stage, edit the label field under main in GitVersion.yml:

Stagelabel valueExample Output
Betabeta2.0.0-beta.1
Release Candidaterc2.0.0-rc.1
Stable Release'' (empty)2.0.0

Publishing a Release

Releases follow Semantic Versioning: MAJOR for breaking changes, MINOR for new features, PATCH for bug fixes.

Automated Release Workflow (Preferred)

Two workflows handle the release lifecycle:

Step 1 — Prepare Release (manual trigger):

  1. Go to Actions → Prepare Release → Run workflow.
  2. Pick the release type (beta, rc, stable) and optionally override the version.
  3. The workflow creates a release/vX.Y.Z branch from develop, updates the GitVersion.yml label, and opens a PR into main.
  4. Review the PR — CI runs, branch protections apply.

Step 2 — Finalize Release (automatic on PR merge): When the release PR is merged into main:

  1. Creates an annotated tag (vX.Y.Z or vX.Y.Z-beta)
  2. Creates a GitHub Release with auto-generated notes
  3. Publish fires automatically → NuGet package published
  4. Opens a back-merge PR (maindevelop) to keep branches in sync

Manual Release Steps

If you need to release manually:

  1. Ensure develop is ready: all changes committed, CI passing.

  2. Merge develop into main:

    powershell
    git checkout main
    git pull upstream main
    git checkout develop
    git pull upstream develop
    git checkout main
    git merge develop
    # Fix any merge conflicts
    
  3. Update the pre-release label in GitVersion.yml if changing stages (e.g., betarc'').

  4. Tag the release on main:

    powershell
    git tag vX.Y.Z -a -m "Release vX.Y.Z"
    
  5. Push atomically:

    powershell
    git push --atomic upstream main vX.Y.Z
    
  6. Monitor CI: the Publish workflow builds and pushes to NuGet. It also triggers an update to Terminal.Gui.templates for stable releases.

  7. Create a GitHub Release at Releases with auto-generated release notes.

  8. Merge main back into develop:

    powershell
    git checkout develop
    git pull upstream develop
    git merge main
    git push upstream develop
    

CI/CD Workflows

All workflows are in .github/workflows/:

WorkflowTriggerPurpose
prepare-release.ymlManual dispatchCreates a release PR from developmain with label updates
finalize-release.ymlRelease PR merged to mainCreates tag, GitHub Release, back-merge PR to develop
publish.ymlPush to main or develop, version tagsBuilds Release config, packs, and publishes to NuGet.org
release.ymlManual dispatch(Legacy) Direct tag-and-release on main; superseded by prepare/finalize
build-validation.ymlPush/PR to main or developBuilds all configurations to validate compilation
unit-tests.ymlPush/PR to main or developRuns all unit tests
api-docs.ymlPush to developBuilds and deploys API docs to GitHub Pages
codeql-analysis.ymlPush/PR to main or developCodeQL security analysis
integration-tests.ymlPush/PR to main or developIntegration tests
stress-tests.ymlPush/PR to main or developStress tests

V1 Legacy Branches

Terminal.Gui V1 (latest: v1.19.0) is maintained on separate branches:

BranchPurpose
v1_releaseV1 stable releases (equivalent of main for V1)
v1_developV1 development (equivalent of develop for V1)

V1 follows the same GitFlow model as V2 but is in maintenance-only mode. The V1 NuGet package is Terminal.Gui 1.x. V1 API docs are published from v1_release to a separate GitHub Pages path.

These branches are not configured in GitVersion.yml (the config was removed to avoid interference with V2 versioning). V1 releases are tagged manually (e.g., v1.19.0).

NuGet Package

  • Package: nuget.org/packages/Terminal.Gui
  • Auto-published on every push to main or develop (pre-release versions from develop, stable versions from main)
  • Pre-release versions (e.g., 2.1.0-develop.42) are marked as pre-release on NuGet

Local Package Development

When building in Release configuration, the .csproj automatically:

  1. Copies .nupkg and .snupkg to ../local_packages/
  2. Pushes the package to the local NuGet cache

Use the local_packages folder as a local NuGet source to test packages before publishing:

powershell
dotnet build Terminal.Gui/Terminal.Gui.csproj -c Release
# Package is now in local_packages/ and your global NuGet cache

Documentation

Contributing

See CONTRIBUTING.md for build/test instructions, coding conventions, and PR guidelines.