Software Release Versioning
Software release versioning assigns stable identifiers to published software so people and tools can distinguish releases and reason about compatibility. A versioning policy explains what each identifier means and when it changes.
itDevOps and software delivery | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Intro
Software Release Versioning
A version is a stable name for a specific software release. The name helps people and tools answer three questions: which release is this, how does it relate to other releases, and what upgrade risk does the publisher claim?
The number alone cannot answer those questions. It gains meaning from a versioning policy. A project might use Semantic Versioning to describe compatibility, Calendar Versioning to describe release time, or an ecosystem-specific scheme such as Python's version format. The durable skill is choosing a policy, defining its contract, and applying it consistently.
Versioning is not the same as source control. A Git tag can mark the commit used for a release, but the version can also appear in package metadata, file names, release notes, and deployed service information. Versioning is not deployment either. You can publish version 2.4.0 without deploying it everywhere, and you can deploy the same version to several environments.
Start with the compatibility contract
Semantic Versioning, usually shortened to SemVer, starts with a declared public API. That API is the contract consumers depend on. It may include callable functions, command-line behavior, configuration fields, data formats, network protocols, or other documented behavior.
This boundary matters because "breaking change" is consumer-facing. A large internal rewrite can be compatible. A one-line change to a documented return value can be breaking. You cannot choose a meaningful version bump until you know what the project promises to preserve.
Under SemVer 2.0.0, a normal version has three non-negative integers:
MAJOR.MINOR.PATCH
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://semver.org/
Supports
- Public API requirement and major, minor, patch change classification
- Normal version syntax, segment reset behavior, and initial development
- Pre-release syntax and precedence
- Build metadata syntax and exclusion from precedence
- Released package contents must not be modified
- https://packaging.python.org/en/latest/specifications/version-specifiers/
Supports
- Python version identifier segments, normalization, and ordering
- Dependency version specifiers as ecosystem-specific consumer constraints
- Distinction between public, pre, post, development, and local versions
- https://calver.org/overview.html
Supports
- Calendar Versioning as date-based release versioning
- Multiple documented calendar schemes and segment vocabulary
- Selection of a scheme to fit project needs
- https://git-scm.com/docs/git-tag
Supports
- Annotated tag data and optional signatures
- Annotated tags intended for releases and lightweight tags for temporary labels
- Risks of replacing a tag after consumers have fetched it
- https://www.conventionalcommits.org/en/v1.0.0/
Supports
- Structured commit message format
- Fix, feature, and breaking-change mappings to SemVer release types
- Other commit types have no implicit SemVer effect without a breaking marker
- https://keepachangelog.com/en/1.1.0/
Supports
- Changelog as a curated chronological list of notable changes
- Version entries, release dates, grouped change types, and Unreleased section
- Commit logs and consumer-facing changelogs serve different purposes
- https://semantic-release.gitbook.io/semantic-release
Supports
- Automated version determination, release-note generation, tagging, and publication
- Use of structured commit conventions in continuous integration
- Ordered release steps and requirements
- https://github.com/sindresorhus/awesome
Supports
- Discovery of the curated Continuous Integration and Continuous Delivery list
- https://github.com/cicdops/awesome-ciandcd
Supports
- Discovery of Jenkins, GoCD, and Open Build Service as release ecosystem tools
- https://www.jenkins.io/doc/book/pipeline/
Supports
- Jenkins Pipeline as a version-controlled model of build, test, and deployment stages
- Awesome Links rationale for Jenkins Pipeline
- https://docs.gocd.org/current/introduction/concepts_in_go.html
Supports
- GoCD pipelines, stages, jobs, materials, dependencies, and artifacts
- Awesome Links rationale for GoCD
- https://openbuildservice.org/help/manuals/obs-user-guide/art-obs-bg
Supports
- Open Build Service builds and distributes packages and images from source
- Multiple operating-system and architecture targets
- Awesome Links rationale for Open Build Service