Versioning Strategies

🚀Versioning Strategies

Stable

Choose the strategy that best matches your project's release workflow.

Commandcusty version

📦Category

Versioning

🚀Quick Command

custy version update

---

strategyversion

---

Overview

Custy separates version generation from version synchronization.

A versioning strategy determines what the next version should be.

Once the version has been generated, Custy synchronizes that version across the appropriate project files.

---

💡Multiple Strategies, One Workflow

Every supported strategy ultimately produces a version number.

The remaining synchronization workflow is identical regardless of which strategy generated that version.

---

Semantic Versioning (SemVer)

SemVer is the default strategy for many projects.

Typical versions look like:

v1.4.2
v2.0.0-beta.1
v3.1.0+build.42

SemVer is widely recognized by Git hosting platforms and is recommended for most applications and libraries.

---

PEP 440

PEP 440 follows Python's official version specification.

Typical versions include:

1.4.2
2.0.0rc1
2.0.0.post1
2.0.0.dev1

Python projects commonly use this strategy because packaging tools understand the format.

---

Commitizen

The Commitizen strategy derives the next version from conventional commit history.

Projects already using Commitizen can integrate directly with Custy while continuing to follow their existing release workflow.

---

Date Strategy

The Date strategy generates versions using the current release date.

Examples include:

2026.07.09

This strategy is useful for projects whose releases are primarily organized by calendar dates rather than incremental version numbers.

---

Git Count Strategy

The Git Count strategy derives the version from repository history.

A simple example is:

v125

where the version reflects the number of commits or another repository-based counting method.

This strategy is useful for projects that prefer automatically increasing identifiers without maintaining traditional semantic versions.

---

Choosing a Strategy

A common recommendation is:

Project Type	Recommended Strategy
General applications	SemVer
Python packages	PEP 440
Conventional Commits	Commitizen
Calendar-based releases	Date
Continuous internal builds	Git Count

Different projects have different release requirements, and Custy allows each project to adopt the strategy that best fits its workflow.

---

ℹ️Project Detection

Version generation and project synchronization are independent concepts.

For example, a version may be generated using SemVer while Custy automatically converts it into a PEP 440-compatible format when updating Python project files.

---

What's Next?

Continue to the Workflow page to see how Custy prepares, generates, and applies version updates regardless of the selected strategy.