A SemVer-compatible versioning system with {head}.{yearweek}.{build} format, where only the head number is manually set.
HeadVer is a versioning specification that provides a structured, automated alternative to traditional Semantic Versioning (SemVer). It uses a {head}.{yearweek}.{build} format where only the head number is manually set, while the year-week and build numbers are automatically generated, simplifying release management and ensuring incremental, traceable versions.
Development teams, DevOps engineers, and release managers who want to automate versioning, reduce manual errors, and have clear, time-based version identifiers.
It eliminates common versioning debates and errors by automating most of the version number, provides built-in age tracking via ISO-8601 week dates, and guarantees unique releases with incremental build numbers.
SemVer compatible version specification that has {head}.{yearweek}.{build} system.
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Only the head number requires manual setting, reducing human error and eliminating 'forgot to update version' commits, as {yearweek} and {build} are auto-generated from the README examples.
The {yearweek} part uses ISO-8601 week dates, allowing developers to instantly see how old a version is, which aids in support and issue tracking, as highlighted in the benefits section.
Auto-incremental build numbers ensure every release has a distinct version, preventing duplicates even if manual updates are missed, as emphasized in the rules.
HeadVer is designed to work with existing x.y.z systems, making it easy to adopt without breaking current workflows, as stated in the introduction and benefits.
By collapsing versioning to one manual number, HeadVer loses the patch/minor/major distinctions that SemVer uses to signal breaking changes or feature additions, which might confuse dependency management.
Implementing {yearweek} requires accurate ISO-8601 week date calculations, which have edge cases (e.g., year boundaries) shown in the validation table, making it error-prone for custom implementations.
The system assumes a build server is available to stamp incremental build numbers, as recommended in the rules, which may not be feasible for all projects or could tie versioning to specific infrastructure.