Bosh sahifa Wiki Versioning

Versioning

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:

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

SemVer 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:

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.

Artifact metadata:

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:

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