Custom Versioning Mechanism Guide
This document defines a custom versioning scheme designed to better reflect development stages and use-case-driven releases for an open-source software library. It introduces primary version labels, release types, and optional qualifiers for internal workflows.
1. Primary Version Labels
The versioning mechanism consists of three main labels:
1.1 Prototype
Format:
n.x.xPurpose: Represents early-stage or conceptual iterations of the software.
Use Case: Initial experiments, incomplete functionality, and early design validations.
1.2 Feature
Format:
N.x.yPurpose: Introduces new, stable features in a forward-compatible manner.
Use Case: Major functional updates that do not break existing contracts.
1.3 Quick Fix
Format:
N.M.xPurpose: Contains minor patches, hotfixes, or non-breaking adjustments.
Use Case: Bug fixes, security patches, or documentation updates.
2. Release Types
2.1 Long-Term Support (LTS)
Stability: Prioritized for reliability and long-term usage.
Support: Receives regular Quick Fix Packs and security updates.
2.2 Innovation Release
Stability: Incorporates newer features and improvements.
Support: Shorter support window; intended for users who need latest capabilities.
3. Update Packs
3.1 Prototype Update Pack
Transition: From one prototype version (
n.x.x) to another (m.y.y).Contents: Experimental changes, revised APIs, architectural changes.
3.2 Feature Pack
Transition: From one Feature version (
N.x.y) to another (N.z.w).Contents: New features, performance improvements, deprecations.
3.3 Quick Fix Pack
Transition: From one patch version (
N.M.x) to another (N.M.y).Contents: Bug fixes, security patches, minor internal tweaks.
4. Optional Internal Labels
These are metadata tags appended to versions for internal or pre-release stages.
Examples:
0.1.0-rc— Release Candidate0.1.0-precert— Pre-Certification0.1.0-test— Internal Testing Build
5. Notes
This versioning scheme supports clarity in communication across teams and users.
Automation pipelines and changelogs should reflect these version types and transitions.
Internal qualifiers help in CI/CD pipelines, QA processes, and release readiness evaluations.
6. Recommendations
Enforce tagging conventions in Git workflows.
Document version transitions in changelogs.
Establish CI checks for validating version consistency.
This structured versioning mechanism aligns development workflows with software maturity and stability expectations, providing a clear roadmap for end users and contributors alike.
Comments
Post a Comment