Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Versioning: local builds as 0.0.0 and allow x.y.0 as the first release of a prefix

Open
  • Is something wrong?
#56 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
68/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp
Domain
build-system, cli, documentation, release, testing-qa

Research direction

Start with the release workflow and the csproj versioning comment, then read release-notes/AGENTS.md and docs/Instructions-Deployment.md. Run ReleaseNotesCatalogTests to identify existing assumptions. Done means local builds use the proposed version, a new prefix releases as x.y.0, later releases increment the patch, and the documentation and comments match.

Written by the indexing model from the issue text.

Description

Priority: P2 Type: DevOps

Today local builds are <VersionPrefix>.0 (0.3.0) and the release workflow computes the next patch from existing tags, so the first release on a new prefix is x.y.1 and release-notes/AGENTS.md reserves patch-zero for developer builds. That made this release 0.3.1 when 0.3.0 was intended.

Proposal:

  • Local builds use 0.0.0-local (or 0.0.0) so a dev build can never be confused with a published one and tp --version makes it obvious.
  • The workflow starts at .0 when no tag exists for the prefix, and .N+1 otherwise.
  • release-notes/AGENTS.md, docs/Instructions-Deployment.md and the csproj comment updated to match, and ReleaseNotesCatalogTests checked for assumptions.

Do this before the 0.4 release so it can be 0.4.0.

Dominant language
C#
Stars
3
Forks
0
Avg merge
7m
Merged PRs (30d)
30

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

  • No Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from SSWConsulting/TimePro.Tools

All issues in SSWConsulting/TimePro.Tools

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.