Introducing Rhythm Versioning

RhyVer combines version tracking with calendar dates (year, quarter, week) to help teams maintain regular release schedules and align software updates with business planning cycles.

Rhythm versioning (RhyVer) helps teams maintain momentum and follow a release cadence. Using the format vMAJOR.YYQ#.WEEK.STORY, it combines semantic versioning principles with granular temporal context, creating a natural rhythm for software releases.

For example, v2.24Q4.45.32 indicates a major version 2 release from the year 2024, Q4, ISO week 45, with 32 backward compatible changes, enabling predictable release cycles and better alignment with business goals.

vMAJOR.YYQ#.WEEK.STORY[-PRERELEASE][+BUILD]

Example: v2.24Q4.45.32-rc.2
          │ │    │  └──────  Stories
          │ │    └─────────  ISO week
          │ └──────────────  Year & quarter
          └────────────────  Major version

Given a version vMAJOR.YYQ#.WEEK.STORY, increment the:
— MAJOR version when you make API compatibility changes.
— YYQ# to match the current year and quarter.
— WEEK number to match the ISO week (1–53).
— STORY for backward compatible changes that do not change the API.

Why Use Rhythm Versioning?

A structured versioning approach that aligns development with business cycles, making release patterns and timing clear to stakeholders.

Release discipline
— Enforces a regular release cadence through week-based versioning.
— Makes it obvious when releases are falling behind schedule.
— Helps teams maintain momentum.

Business alignment
— Quarter designations align directly with business planning cycles.
— Stakeholders can immediately understand release timing.
— Simplifies reporting by matching fiscal/planning periods.

Reading Your Business Rhythm

Interpreting version numbers as indicators of development pace and business cycles, with markers for healthy and concerning patterns.

v2.24Q4.45.32
 │   │  │  └────  Weekly wins
 │   │  └───────  Calendar pulse
 │   └──────────  Business cycle
 └──────────────  Major changes

Release Sequence
──────────────────────────────────────────────────
Week 27 │ v2.24Q3.27.0     Release of milestone 01
        │ v2.24Q3.27.1     Polishing
        │ v2.24Q3.27.2     Qualitative feedback
        │
Week 28 │ v2.24Q3.28.0     Design improvements
        │ v2.24Q3.27.1     Release of milestone 02


Risk Indicators
──────────────────────────────────────────────────
High risk
└── No releases for more than 2 weeks
└── Hotfix ratio greater than 20%

Low risk
└── Release gap of 1 week
└── Story count drops by 25%

Using in Design

Design files typically evolve incrementally with each iteration, so the granular “STORY” component is not as relevant. The version can be kept at the “WEEK” level. Use the Rhythm Versioning format as the commit messages when saving new versions to make the version history more meaningful and aligned with development.

Commit
v2.24Q4.45.x     // Major.YYQ#.Week  
v2.24Q4.46.x     // Week changes
v3.24Q4.46.x     // Major version changes

Using With NPM

Convert RhyVer to semantic versioning for npm compatibility.

{
  "name": "package-name",
  "rhyver": "v2.24Q4.45.32",   // Store full RhyVer
  "version": "2.45.32"         // Simplified from v2.24Q4.45.32
}

RhyVer           │ npm
v2.24Q4.45.32    │ 2.45.32     // Major.Week.Story
v2.24Q4.45.33    │ 2.45.33     // Story changes
v3.24Q4.46.0     │ 3.46.0      // Major version changes

“Rhythm Versioning” or “RhyVer” specification was originally authored by Abhimanyu Rana. To provide feedback, please open a GitHub issue.

Read the Full RhyVer Specification (๑•̀ㅂ•́)و✧