Support of calver

[fdubost]

Hi, thanks a lot for this great tool.

Some teams in my company use the calver convention instead of semver. We want to globally migrate to release-please (we have an homemade tool for now) but we can't because it only support semver. Is it planned to support other versioning convention, or is there a way to use calver with release-please?

Thanks !

[chingor13]

There is an interface for VersioningStrategy which can bump versions based on the commit messages. It is possible to implement your own and even register it in the versioning factory

[wikando-ck]

I have added a draft for this in #2637.

I'd like to discuss/mention a few things:

1) option-naming
I've opted for date-format first, then realized that CalVer.org talks about a scheme and that it includes more than just date fields. So i've renamed this to calver-scheme, which is fine i think. We could opt for versioning-scheme or versioning-pattern, but this is very generic and could be in the way in further development - it could also be used for other formats, though.

2) placeholders
I went with simple uppercase strings for the placeholders for the scheme (like YYYY, YY, 0D, etc).
I use a simple trick to avoid erroneaous replacement of e.g. YYYY with the value/regex for YY, which is sorting them.
I noticed however, that there is a template-like replacement "language" for the pull-request-title-pattern already.
It might be better aligned to stay with this and use ${YYYY}, ${DD}, ${MINOR} etc..

3) optional modifiers
I have not added optional identifiers, eventhough we use them ourselves.
These would add a modifier only when there already is a version with the calVer-scheme in place.

2025.12.16 # exists
2025.12.16-1 # would be the next version, as the zero based increment is the one without the modifier

This could be added as a separate option, but there are difficulties with parsing and calculating and the question what can be placed in that modifier (typically -MINOR, but could also be -MINORMICRO).

Currently not implemented. Modifiers, if desired must be part of the scheme.

4) week calculation
This is currently not specified enough in CalVer.
However, there is a PR regarding this: mahmoud/calver#31
Currently I went with what felt natural for me as a central european and the spec (gregorian calendar, since start of year, UTC).
This puts January 1st into Week 1 and rolls the weeks on Mondays.
If the linked PR is merged, we might need another option to specify different strategies for this or just stay opinionated.

5) not resetting MAJOR on a new calendar period
some might use a format that uses calendar based versioning, but still allows differentiating BC-Breaks.
This could be a scheme like: MAJOR.YY.0M-MINOR.
You want the MAJOR to only change on BC-Breaks in that case, not on calendar period changes of the calVer parts.
This is the current behaviour due to the way Versions are parsed.

[Matheus-RR]

Some real-world CalVer patterns from products I've been tracking that might help inform the design:

Common schemes in the wild:

• Ubuntu: YY.0M (24.04, 24.10) — no patch component, point releases use YY.0M.MINOR (24.04.1)
• JetBrains IDEs: YYYY.MINOR (2025.1, 2025.2) — MINOR resets each year
• Docker: YY.0M.MICRO (27.0.1) — looks like semver but the major is actually a year
• Firefox/Chrome: MAJOR.MINOR.MICRO — sequential but people sometimes confuse this with CalVer because of the rapid cadence
• pip/pipx: YYYY.MINOR or YY.MINOR.MICRO

On point 1 (naming): calver-scheme seems right. versioning-scheme is too generic and would conflict if you ever want to add other versioning strategies (like romantic versioning, 0ver, etc.).

On point 3 (modifiers): This is the hardest part in my experience. The Ubuntu pattern is the most common one — YYYY.0M as the base, with a sequential integer suffix for point releases. I'd suggest supporting at least -MINOR as a modifier since that covers the majority of real-world cases. The more exotic modifiers (-MINORMICRO) can probably wait.

On point 5 (not resetting MAJOR): This is actually a really important edge case. Terraform used to do MAJOR.MINOR.PATCH where MAJOR had CalVer-like semantics but MINOR/PATCH were semver. Supporting a hybrid scheme (MAJOR.YY.0M) where only some components are date-based would cover this pattern and the Ubuntu point-release pattern.

Great to see this getting traction — CalVer support would make release-please viable for a much larger set of projects.