Versioning — dastur, API, package, schema yoki hujjatning vaqt davomida o‘zgargan holatlarini identifikator bilan ajratish tizimi.
Versiya foydalanuvchi va boshqa komponentlarga qaysi release ishlatilayotganini, qanday moslik kutilishini va yangilanish tartibini tushunishga yordam beradi.
Faqat raqam berishning o‘zi yetarli emas; versiya siyosati va compatibility contracti ham kerak.
Version formati
Keng tarqalgan format:
MAJOR.MINOR.PATCH
Masalan:
2.4.1
Har qismning ma’nosi qo‘llanayotgan versioning siyosatiga bog‘liq.
Semantic Versioning
Semantik versiyalashda:
- MAJOR — backward-compatible bo‘lmagan o‘zgarish;
- MINOR — backward-compatible yangi imkoniyat;
- PATCH — backward-compatible bugfix.
Misol:
1.3.2 → 1.3.3 patch
1.3.3 → 1.4.0 minor
1.4.0 → 2.0.0 major
Bu model public API aniq belgilanganida foydali.
Public API
SemVer uchun “public API” nima ekanini aniqlash zarur.
U quyidagilarni qamrab olishi mumkin:
- function signature;
- CLI option;
- config format;
- environment variable;
- network response;
- database schema;
- behavior;
- error code;
- performance guarantee;
- file format.
Faqat source methodlar public contract emas.
Pre-release
Barqaror release’dan oldingi versiya:
2.0.0-alpha.1
2.0.0-beta.2
2.0.0-rc.1
Pre-release oddiy release’dan past tartibda hisoblanadi.
Ma’nolar:
- alpha — erta, katta o‘zgarish mumkin;
- beta — featurelar shakllangan, test davom etadi;
- release candidate — yakuniy release nomzodi.
Build metadata
1.4.0+build.582
1.4.0+sha.abc123
Release identity haqida qo‘shimcha ma’lumot beradi.
Precedence hisobida build metadata odatda versiya ustunligini o‘zgartirmaydi.
Calendar Versioning
Versiya sana asosida beriladi.
Misollar:
2026.07
2026.07.14
26.7
Bu release vaqtini aniq ko‘rsatadi.
Calendar versioning compatibility darajasini avtomatik bildirmaydi.
Incremental build number
Har build ketma-ket raqam oladi.
build 10452
CI artifactni aniq topishga yordam beradi.
Marketing version va internal build number alohida bo‘lishi mumkin.
Git commit version
Development artifact commit hash bilan identifikatsiya qilinadi.
Masalan:
2.4.0-dev+g1a2b3c4
Commit hash source holatini topadi, ammo dependency va build environmentni to‘liq ifodalamaydi.
Version constraint
Dependency foydalanuvchisi ruxsat etilgan versiya oralig‘ini belgilaydi.
Misollar:
- aniq
2.4.1; >=2.4;<3.0;- compatible
^2.4; - patch range
~2.4.1.
Operator semantikasi package managerga qarab farq qilishi mumkin.
Floating version
latest, 2.x yoki keng range har install paytida boshqa artifact tanlashi mumkin.
Afzalligi — update avtomatikroq.
Kamchiligi — reproducibility past.
Lock file aniq resolved versiyani saqlaydi.
Backward compatibility
Yangi version eski client input va chaqiriqlarini qabul qilsa backward-compatible.
Masalan, response’ga optional field qo‘shish ko‘pincha mos.
Ammo eski client unknown fieldni rad etsa, amalda breaking change bo‘lishi mumkin.
Compatibility real consumer xatti-harakatiga ham bog‘liq.
Forward compatibility
Eski component kelajakdagi yangi formatning ayrim qismini qabul qila olsa forward-compatible.
Usullar:
- unknown fieldni e’tiborsiz qoldirish;
- reserved field;
- feature negotiation;
- tolerant parser.
Juda tolerant parser xavfsizlik va xato aniqlashni zaiflashtirishi mumkin.
Source compatibility
Eski source yangi library bilan qayta compile bo‘ladi.
Bu binary compatibility’dan farq qiladi.
Method mavjud, ammo overload resolution o‘zgarsa source behavior ham o‘zgarishi mumkin.
Binary compatibility
Eski compile qilingan application yangi library bilan qayta compile qilinmasdan ishlaydi.
ABI:
- symbol;
- calling convention;
- structure;
- vtable;
- type layout
saqlanishi kerak.
API versioning
Tarmoq API versiyasi:
orqali ko‘rsatilishi mumkin.
Misol:
/api/v2/orders
Bir server bir necha versiyani vaqtincha qo‘llashi mumkin.
Schema versioning
Database va message schema ham versiyalanadi.
O‘zgarishlar:
- yangi optional field;
- field rename;
- type o‘zgarishi;
- index;
- constraint;
- table split.
Rolling deploymentda eski va yangi application bir muddat bir schema bilan ishlaydi.
Migration
Breaking o‘zgarish uchun migration yo‘li beriladi.
Tarkib:
- nima o‘zgardi;
- eski va yangi misol;
- avtomatik vosita;
- deadline;
- rollback;
- data migration;
- compatibility window.
Faqat changelogdagi “breaking” so‘zi yetarli emas.
Deprecation
Eski imkoniyat saqlanadi, ammo kelajakda olib tashlanishi e’lon qilinadi.
Deprecation quyidagilarni bildiradi:
- replacement;
- warning;
- sabab;
- removal version;
- migration guide.
Foydalanuvchiga real o‘tish vaqti beriladi.
Changelog
Har release o‘zgarishlari:
- added;
- changed;
- fixed;
- deprecated;
- removed;
- security
bo‘yicha yoziladi.
Commit log avtomatik ravishda foydalanuvchi uchun yaxshi changelog bo‘lavermaydi.
Release tag
Version control’da release commitga tag qo‘yiladi.
Tag:
bo‘lishi mumkin.
Tagni keyin boshqa commitga ko‘chirish supply-chain ishonchini buzadi.
Artifact version
Source version bilan binary artifact aniq bog‘lanadi.
- version;
- commit;
- build number;
- toolchain;
- platform;
- dependency lock;
- checksum
ni saqlashi mumkin.
Parallel support
Bir vaqtning o‘zida:
qo‘llanishi mumkin.
Har branch uchun support muddati va patch siyosati belgilanadi.
Major version nol
SemVer’da 0.y.z initial developmentni bildiradi. Public API beqaror bo‘lishi mumkin.
Shunga qaramay, production foydalanuvchilar mavjud bo‘lsa o‘zgarishlarni tartibli boshqarish kerak.
Version comparison
Versiya oddiy matn sifatida solishtirilmaydi.
Masalan:
1.10 > 1.9
lekin string tartibida aksincha chiqishi mumkin.
SemVer parser numeric segment va pre-release qoidalarini tushunadi.
Diagnostika
Versioning muammosida:
- actual runtime version;
- package lock;
- API version;
- schema version;
- artifact build;
- compatibility;
- pre-release;
- cache;
- duplicate library;
- migration holati
tekshiriladi.
“Eng yangi” versiya qaysi channel, platforma va support branch nazarda tutilganiga qarab farq qilishi mumkin.
Bog‘liq tushunchalar
Semantic Versioning, Calendar Versioning, Backward compatibility, Binary compatibility, API versioning, Deprecation, Changelog, Release, Migration, Lock file