1# **webette Versioning Guide**
2
3webette uses a **hybrid versioning model** designed to be simple, predictable, and expressive.
4It combines a high-level _generation number_ with a _calendar-based release cycle_.
5
6This format is:
7
8```
9v<generation> <YYYY.MM>.<increment>
10```
11
12Example:
13
14```
15v1 2025.12.1
16```
17
18---
19
20## **1. Components of the Version Number**
21
22### **Generation (`v1`, `v2`, …)**
23
24A broad milestone.
25This number only changes when webette reaches a significant stage in its evolution —
26major architectural improvements, new foundations, or a major shift in how the tool works.
27
28This is **not** tied to breaking changes.
29It’s simply a way to mark eras of the project.
30
31### **Calendar Release (`YYYY.MM`)**
32
33A datestamp that indicates the release cycle.
34
35- `YYYY` → year
36- `MM` → month
37
38This makes versions easy to interpret at a glance and avoids ambiguity around compatibility rules.
39
40### **Increment (`.0`, `.1`, `.2`, …)**
41
42A sequential counter for releases within the same month.
43It resets at the beginning of each new month.
44
45Examples:
46
47- First release of the month → `.0`
48- Small follow-up or fix → `.1`
49- Additional feature or patch → `.2`
50
51---
52
53## **2. Examples**
54
55```
56v1 2025.12.0 → First December 2025 release
57v1 2025.12.1 → Follow-up release: fixes or additions
58v1 2026.01.0 → New month, counter resets
59v2 2026.05.0 → New project era / major milestone
60```
61
62This scheme sorts naturally and remains easily readable.
63
64---
65
66## **3. How to Decide the Generation Number**
67
68Increase the generation only when:
69
70- a foundational refactor lands,
71- the internal architecture evolves significantly,
72- the philosophy or target audience of webette shifts,
73- or when you feel the project enters a new “chapter.”
74
75Do _not_ increment the generation for:
76
77- normal feature additions,
78- breaking changes,
79- bug fixes,
80- plugin API updates.
81
82Generations represent **eras**, not compatibility.
83
84---
85
86## **4. Why This Model?**
87
88webette’s versioning system is designed to avoid the confusion of traditional SemVer while remaining meaningful:
89
90- **Readable:** users immediately know _when_ a version came out.
91- **Flexible:** no need to classify changes as major/minor/patch.
92- **Structured:** generations give long-term coherence.
93- **Release-friendly:** perfect for a tool that evolves incrementally and experimentally.
94
95It reflects the way webette grows: organically, creatively, and with clarity.
96
97---
98
99## **5. Summary**
100
101The official version format is:
102
103```
104v<generation> <YYYY.MM>.<increment>
105```
106
107- **Generation** → big milestones
108- **Date** → when the release happened
109- **Increment** → multiple releases in the same month
110
111This model is simple, descriptive, future-proof, and works beautifully with webette’s philosophy.