Skip to main content

VerNum

Configurable version numbering for project releases

(Similar to GitVersion)

Python module/CLI installation

The VerNum Python module is distributed as a PyPI module and can be installed like any other.

Install with pipx to avoid dependency collisions

pipx install vernum

Commands

The vernum max command

Takes a list of version numbers and based on the configued numbering scheme, returns the highest value in the list.

echo "1.4.0\n1.4.1\n1.5.0" | vernum max

The vernum next command

Takes a single version number and, based on the configured numbering scheme and the selected increment, outputs the next version number.

echo "3.4.5" | vernum next patch

The vernum limit command

Takes a single version number and, based on the onfigured numbering scheme and provided limits, triggers an error if the version number falls outside the limit. Only a minimum limit is currently supported (see configuration below).

Schemes

VerNum supports multiple "schemes" for version numbering.

Scheme Description Increments Example
major Just a single version number major 4
minor Major, dot, minor major minor 4.2
patch Major, dot, minor, dot patch major minor patch 4.2.1
minor-alpha-beta Major, dot, minor, dot, and either a patch, alpha, or beta major, minor, patch, alpha, beta 4.3.alpha2

Schemes support an optional "v" before the version number for inputs, including from Git, but output the result without a "v".

The default scheme is patch.

Schemes with prerelease versions

Some schemes have prerelease versions (alpha, beta) with varying syntax. The basic approach to incrementing is to assume a preference for starting with alpha, then going to beta. So, for example, if the current version is at 1.2.3 and the operator requests a patch update, the version becomes, for example, 1.2.4-alpha (depending on the scheme itself).

Increments only go forward, so avoid attempting to move from beta to alpha.

FOr the minor-alpha-beta scheme:

  • major changes e.g. 5.6.2 to 6.0.alpha1
  • major-zero changes e.g. 5.6.2 to 6.0.0
  • minor changes e.g. 5.6.2 to 5.7.alpha1
  • minor-zero changes e.g. 5.6.2 to 5.7.0
  • beta changes e.g. 5.7.beta3 to 5.7.beta4
  • alpha changes e.g. 5.7.alpha8 to 5.7.alpha9
  • patch changes e.g. 5.6.beta6 to 5.6.0
  • patch changes e.g. 5.6.2 to 5.6.3

For the patch-hyphen-al-be scheme:

  • major changes e.g. 5.6.2 to 6.0.0-alpha
  • major-zero changes e.g. 5.6.2 to 6.0.0
  • minor changes e.g. 5.6.2 to 5.7.0-alpha
  • minor-zero changes e.g. 5.6.2 to 5.7.0
  • patch changes e.g. 5.6.2 to 5.6.3-alpha
  • patch-zero changes e.g. 5.6.2 to 5.6.3
  • beta changes e.g. 5.7.3-alpha to 5.7.3-beta
  • patch changes e.g. 5.7.3-alpha to 5.7.3
  • patch-zero changes e.g. 5.7.3-beta to 5.7.3
  • The major, major-zero, minor, and minor-zero increments work as expected

Use with Git tags

We designed VerNum to use with Git tags, and recommend using the history of tags in the default branch as the source of truth for version numbers.

The example below demonstrates one way to use VerNum with Git tags.

git tag --list --merged HEAD | vernum max | vernum next patch > .version
git tag -a "$(cat .version)" -m "$(cat .version)"

Keep the following pointers in mind when using VerNum with Git.

  • CD to the root of the project before running it
  • Be on the branch that you use for releases (i.e. master)
  • Be fully up-to-date in git (i.e. merged, committed, and pushed)

Configuration and input

VerNum uses the WizLib framework for configuration and input control.

  • Input to commands can come through stdin
  • Alternatively, use the vernum --input <filename> to pull input from a file
  • The scheme can be selected with an environment variable $VERNUM_SCHEME
  • Alternatively, the scheme can be set in a YAML configuration file; the application will try, in order:
    • A config file location designated with vernum --config <filename>
    • A config file location designated with a $VERNUM_CONFIG environment variable
    • .vernum.yml in the local directory
    • .vernum.yml in the user's home directory

We recommend placing a .vernum.yml file in the project directory and committing it to the project's Git repository, so different environments use the same scheme.

The format for the YAML file is simple (allowing for other forms of configuration in the future):

vernum:
  scheme: minor
  limit:
    min: '4.2'

Metadata

Release files for vernum 8.0.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for vernum 8.0.0
File Size Uploaded
vernum-8.0.0.tar.gz 6.2 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for vernum 8.0.0
File Interpreter ABI Platform
vernum-8.0.0-py3-none-any.whl Python 3 none any Details

Total release size: 16.9 kB

Release files / vernum-8.0.0.tar.gz

Download URL vernum-8.0.0.tar.gz
Size 6.2 kB
Tags Source
SHA-256 checksum
How to use checksums
195d64fd0039e67d055641450a5226ee6dab930395a334a3deaabfba13b00fe6
BLAKE2b-256 checksum
How to use checksums
bbf697f3180129bb1c5bc6cefd8716cdaaf6d4d203e7470fa80b296573835689
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 2, 2026.

Transparency log

Release files / vernum-8.0.0-py3-none-any.whl

Download URL vernum-8.0.0-py3-none-any.whl
Size 10.8 kB
Tags Python 3
SHA-256 checksum
How to use checksums
114950c65c5f8bccc209ae7a2d37adc8e773575ff30edeb7efd33d8bc608e181
BLAKE2b-256 checksum
How to use checksums
f2594de3357aae30693d86b58bef490776349018bea8a026984c88987f374054
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 2, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

8.0.0 This release

2 release files

7.4.0

2 release files

7.3.1

2 release files

7.3.0

2 release files

7.2.2

2 release files

7.2.1

2 release files

7.2.0

2 release files

7.1.4

2 release files

7.1.3

2 release files

7.1.2

2 release files

7.1.1

2 release files

7.0.2

2 release files

7.0.1

2 release files

7.0.0

2 release files

6.0.2

2 release files

6.0.0

2 release files

5.2.0

2 release files

5.1.1

2 release files

5.1.0

2 release files

5.0.3

2 release files

5.0.2

2 release files

5.0.1

2 release files

5.0.0

2 release files

3.2.1

2 release files

3.2.0

2 release files

3.1.5

2 release files

3.1.1

2 release files

3.0.0

2 release files

2.2.2

2 release files

2.2.0

2 release files

2.1.3

2 release files

2.1.2

2 release files

2.1.1

2 release files

0.0.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page