Project Tick Versioning Scheme (X.Y.Z-N)

Overview

Project Tick uses a structured, time-aware versioning scheme designed to balance development cadence, feature tracking, and packaging revisions:

X.Y.Z-N

This model combines elements of time-based versioning, feature iteration, and distribution-style revision tracking.

---

Version Components

X — Year Index

Represents the number of years since the project started.

• Incremented annually
• Provides long-term timeline context

Example:

• 0 → first year
• 1 → second year
• 2 → third year

---

Y — Half-Year Cycle Index

Represents 6-month development cycles.

• Incremented every 6 months
• Continuous (does not reset each year)

Example:

• 1 → first 6 months
• 2 → second 6 months
• 3 → third 6 months
• 4 → fourth 6 months

This allows versions to map directly to the project timeline.

---

Z — Release Number (Feature Releases)

Represents releases within a given cycle.

• Incremented for each new release containing features or meaningful changes
• Reset when a new cycle begins (i.e., when Y increments)

Example:

2.4.1 → first release in cycle
2.4.2 → second release in cycle

---

N — Revision Number (Fixes / Rebuilds)

Represents revisions of the same release.

• -1 → initial release
• -2+ → bug fixes, rebuilds, or packaging updates

Example:

2.4.2-1 → initial release
2.4.2-2 → first fix
2.4.2-3 → second fix

---

Versioning Rules

Cycle Transition

• When a new 6-month cycle begins:

  • Y increments
  • Z resets to 0

Example:

2.3.5-2 → 2.4.0-1

---

Release Updates

• New features or significant changes:

  • Increment Z
  • Reset N to 1

Example:

2.4.2-3 → 2.4.3-1

---

Fixes and Revisions

• Bug fixes, rebuilds, or packaging updates:

  • Increment N
  • Do not modify Z

Example:

2.4.2-1 → 2.4.2-2

---

Design Goals

This versioning model is designed to:

• Reflect development timeline clearly
• Separate feature releases from fixes
• Support CI/CD and packaging workflows
• Maintain traceability across releases

---

Example Progression

2.4.2-1  → initial release
2.4.2-2  → fix
2.4.2-3  → fix

2.4.3-1  → new release (features)
2.4.3-2  → fix

→ next cycle

2.5.0-1  → new cycle start

---

Comparison to Other Models

Model	Difference
Semantic Versioning	Not strictly API-based; time-aware
Linux Kernel	Similar incremental logic, but no explicit time mapping
Debian/RPM	Shares revision (-N) concept

---

Summary

The X.Y.Z-N scheme provides a hybrid approach that:

• Encodes time progression (X, Y)
• Tracks feature evolution (Z)
• Captures stability and fixes (N)

It is particularly well-suited for projects with:

• Continuous development
• Frequent releases
• Strong CI/CD and packaging integration