Calendar Versioning — release versiyasining bir yoki bir nechta qismini chiqarilgan yil, oy, kun yoki vaqt davriga bog‘laydigan versiyalash usulidir. Masalan, 2026.07 2026-yil iyuldagi release, 26.7.1 esa shu davrdagi birinchi tuzatish nashrini anglatishi mumkin. CalVer deb qisqartiriladigan yondashuv versiyaning yoshini va release ketma-ketligini ko‘rsatadi, ammo yagona majburiy formatga ega emas.
Formatni belgilash
Loyiha qaysi komponent yil, oy, kun yoki incremental counter ekanini hujjatlashtiradi. To‘rt xonali YYYY yilni aniq beradi, ikki xonali YY esa qisqaroq, lekin uzoq muddatda noaniqlik keltirishi mumkin. Oy va kun nol bilan to‘ldirilishi leksik saralashni osonlashtiradi. Misol formatlar:
| Shakl | Talqin namunasi |
|---|---|
YYYY.MM |
yil va oy release’i |
YY.MM.MICRO |
yil, oy va tuzatish soni |
YYYY.MM.DD |
aniq sana asosidagi release |
Versiya sana bilan bog‘langan bo‘lsa ham vaqt zonasi va release chegarasi belgilanadi. Bir kunda bir nechta artefakt chiqsa, qo‘shimcha counter yoki build metadata kerak. Nashr qilingan artefaktning raqami qayta ishlatilmaydi.
Semantik moslikdan farqi
Semantic Versioning MAJOR o‘zgarishini public API buzilishi bilan bog‘laydi. Calendar Versioningda esa 2026.07dan 2026.08ga o‘tish compatibility haqida o‘z-o‘zidan hech narsa demaydi. Breaking change, deprecation va migratsiya alohida siyosat, release note yoki compatibility kanali bilan bildiriladi.
CalVer muntazam release qilinadigan operatsion tizim, servis, dataset va vositalarda qulay. Foydalanuvchi release qanchalik eski ekanini darhol ko‘radi. Biroq kutubxona dependency resolveri faqat sana raqamiga qarab API mosligini xavfsiz taxmin qila olmaydi.
Qo‘llab-quvvatlash oynasi
CalVer support muddatini release sanasi bilan bog‘lashni osonlashtiradi. Masalan, har aprel release’i uzoq muddatli, qolganlari qisqa muddatli bo‘lishi mumkin. Bu qoida versiya formatining o‘zi emas; support policyda aniq yoziladi. “Oxirgi 12 oy” kabi rolling window foydalanuvchiga upgrade rejasini tuzishga yordam beradi.
Release kechiksa, raqam rejalashtirilgan sana yoki haqiqiy nashr sanasiga bog‘lanishi masalasi oldindan hal qilinadi. Haqiqiy sana operatsion haqiqatni aks ettiradi, marketing sikli esa rejalashtirilgan davr nomini saqlashi mumkin. Aralash yondashuv avtomatlashtirish va auditda chalkashlik tug‘diradi.
Package manager bilan ishlash
Ko‘p package manager raqamli qismlarni SemVerga o‘xshash tartibda solishtiradi, lekin CalVer qiymati sintaktik jihatdan ularning qoidalariga mos bo‘lishi kerak. Masalan, oy 07 tarzida yozilganda ayrim parser leading zeroni qabul qilmasligi mumkin. Registryga nashrdan oldin parser va precedence test qilinadi.
Dependency diapazoni >=2026.1,<2027 deb yozilsa, u butun yil release’larini qabul qiladi, ammo breaking change yo‘qligini anglatmaydi. Ilovalar lock file, integratsion test va controlled update bilan xavfni boshqaradi. Security patch eski calendar release uchun alohida micro raqam bilan chiqishi mumkin.
Release intizomi
CalVer tez-tez chiqarishni majbur qilmaydi. Loyiha versiyani faqat haqiqiy artefakt tayyor bo‘lganda beradi. Source commit, build ID va versiya o‘rtasidagi bog‘lanish provenance metadata bilan saqlanadi. Bir sanada qayta build zarur bo‘lsa, immutable micro release chiqariladi; mavjud tag yoki paket yashirincha almashtirilmaydi.
Changelog har versiyadagi imkoniyat, tuzatish, xavfsizlik va compatibility o‘zgarishini tasniflaydi. Shunday qilib sana operatsion vaqtni, yozma siyosat esa iste’molchiga ta’sirni bildiradi.
Bog‘liq tushunchalar
Semantic Versioning, Release, Version scheme, Support lifecycle, Long-term support, Changelog, Build metadata