ShareX Workflow and Versioning
Scope
This file is the single source of truth for Git and versioning rules that involve:
- Commit and push workflow
- Commit message format
- Version bump behavior
Directory.Build.propsupdates
This supersedes the retired docs/development/RELEASE_PROCESS.md.
Version Source Of Truth
- Treat the root
Directory.Build.propsfile as the working XerahS app version source of truth. - Before any versioned XerahS commit, compare the root version with the highest existing XerahS git tag.
- If the root version is not strictly greater than the latest tag, bump the root version first so the branch carries the next unreleased version.
- Never set version numbers in individual
.csprojfiles. - When bumping version, update every tracked
Directory.Build.propsin the repository that intentionally carries the XerahS app version so values match. - Derived release metadata files, such as
build/windows/chocolatey/xerahs.nuspec, must be synchronized from the root version during release automation. - Tagged releases also generate and smoke-test the Chocolatey
.nupkg, so release metadata underbuild/windows/chocolatey/must stay automation-friendly.
Version Bump Policy
- Bug fix: increment patch only (
0.0.zrule: keep major/minor, increasez). - New feature: increment minor and reset patch.
- Breaking change: increment major and reset minor/patch.
Required Pre-Commit Checks
Before committing and pushing:
git pull --recurse-submodules
git submodule update --init --recursive
dotnet build src/desktop/XerahS.sln
Only continue when build succeeds with 0 errors.
Commit And Push Procedure
- Stage changes:
git add .
- Commit using:
git commit -m "[vX.Y.Z] [Type] concise description"
- Push:
git push
Commit Message Rules
- Prefix XerahS app commits with the root
Directory.Build.props<Version>as[vX.Y.Z], but only after verifying that version is strictly greater than the highest existing XerahS git tag. - Never use a version prefix that is lower than or equal to the latest tag. If the latest tag is already at or above the root version, bump
Directory.Build.propsfirst and then commit with that bumped version. - Include a type token such as
[Fix],[Feature],[Build],[Docs],[Refactor]. - Keep the description concise and specific.
- Submodule-only commits in shared libraries (e.g.
ShareX.ImageEditor): omit[vX.Y.Z]; use[Type] descriptionperAGENTS.md.
Git Hook Expectations
- Keep
.githooksactive (git config core.hooksPath .githooks). - Do not bypass hooks with
--no-verifyunless explicitly requested for emergency use. - If hooks fail, fix issues and recommit.
Documentation And Git
- Commit Markdown documentation changes with related code/config changes.
- Do not leave generated instruction docs uncommitted when they are part of the requested work.
More from sharex/xerahs
design-ui-window
Redesigns or normalises any XerahS Avalonia .axaml page, dialog, or tool window to consistent app quality. Enforces layout, spacing, theming, surfaces, buttons, scrollbars, accessibility, and visual hierarchy. Only changes visuals, layout, and styles; never business logic, bindings, or public view-model API. Reusable by updating target_view_path.
71sharex core standards
License headers, build configuration rules, dependency version guidance, and general coding standards for XerahS
61changelog management
Rules and workflows for updating CHANGELOG.md, including version grouping, consolidation, and commit handling.
59sharex feature specifications
Detailed specifications for Uploader Plugin System and Annotation Subsystem features
58sharex architecture and porting
Platform abstraction rules, porting guidelines, and architecture standards for XerahS
57avalonia-api
Comprehensive reference for Avalonia UI framework including XAML syntax, controls, data binding, MVVM patterns, styling, custom controls, layout system, responsive layout, navigation, and best practices. Covers CommunityToolkit.Mvvm integration, compiled bindings, dependency properties, attached properties, control templates, container queries, and cross-platform development patterns.
38