A simple, folder-driven static-site engine.
bun ssg fs
at dev 111 lines 2.8 kB view raw view rendered
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.