Backward compatibility — tizimning yangi versiyasi eski versiya uchun yaratilgan kirishlar, mijozlar, ma’lumotlar yoki integratsiyalar bilan kelishilgan chegarada ishlashda davom etish xususiyatidir. Masalan, yangi server eski mobil mijoz protokolini qabul qilsa yoki yangi kutubxona avvalgi public API chaqiruvlarini saqlasa, u orqaga mos hisoblanadi. Moslik har doim aniq obyekt va yo‘nalishga nisbatan baholanadi.
Moslik qatlamlari
Source compatibility eski source kod yangi kutubxona bilan qayta kompilyatsiya bo‘lishini anglatadi. Binary compatibility oldin kompilyatsiya qilingan dastur yangi kutubxona bilan qayta build qilinmasdan ishlashini bildiradi. API bir xil ko‘rinsa ham ABI, calling convention yoki struct layout o‘zgarsa binary moslik buzilishi mumkin.
Data compatibility yangi dastur eski fayl yoki schema yozuvini o‘qishini qamrab oladi. Protocol compatibility turli versiyadagi client va server xabar almashishini tekshiradi. Behavioral compatibility esa hujjatlangan natija, xato turi, tartiblash yoki performance chegarasi kabi kuzatiladigan xatti-harakatni saqlaydi.
Evolyutsiya usullari
Yangi maydon qo‘shishda eski reader noma’lum maydonni e’tiborsiz qoldirishi, yangi reader yo‘q maydon uchun xavfsiz default ishlatishi mumkin. Field ID qayta ishlatilmaydi; olib tashlangan maydonning identifikatori reserved qoladi. Required maydon qo‘shish eski producer xabarini yaroqsiz qilishi mumkin, shuning uchun optional qo‘shish odatda xavfsizroq.
APIda yangi optional parametr yoki yangi endpoint qo‘shish ko‘pincha orqaga mos. Mavjud parametr ma’nosini o‘zgartirish, return typeni toraytirish yoki oldin qabul qilingan qiymatni rad etish esa breaking change bo‘lishi mumkin. Default xatti-harakat ham shartnomaning bir qismidir.
Rolling deployment
Distributed tizim yangilanayotganda bir muddat eski va yangi instance birga ishlaydi. Database migration avval expand bosqichida yangi schema elementini qo‘shadi, ikkala kod versiyasi bilan mos yozadi, keyin barcha instance yangilangach contract bosqichida eski elementni olib tashlaydi. Birdan rename qilish rolling deployda eski kodni buzadi.
Xabar formatida producer yangi maydon yuborishdan oldin consumerlar uni qabul qila olishi tekshiriladi. Feature flag yangi yozish formatini bosqichma-bosqich yoqadi. Rollback rejasi yangi versiya yozgan ma’lumotni eski versiya o‘qiy olishini hisobga oladi.
Tekshirish
Compatibility testlar eski mijoz artefaktini yangi serverga, eski ma’lumot fixturelarini yangi readerga va oldingi binaryni yangi dynamic libraryga qarshi ishlatadi. Consumer-driven contract test iste’molchi haqiqatan tayangan so‘rov va javoblarni ifodalaydi. Faqat unit test yangi kodning ichki mantiqini tekshiradi, versiyalararo shartnomani to‘liq qamramaydi.
Golden file testlari serialized bayt yoki hujjat formatini solishtiradi. Ular ataylab qilingan format o‘zgarishida yangilanadi, lekin review o‘zgarishning eski readerga ta’sirini ko‘radi. Telemetry eski client versiyalarining real ulushini ko‘rsatib, olib tashlash vaqtini tanlashga yordam beradi.
Deprecation va chegara
Cheksiz moslik texnik qarzni oshiradi. Deprecation siyosati eski interfeysni belgilaydi, muqobil yo‘l va olib tashlash muddatini beradi. Warning foydalanuvchini topadi, migratsiya qo‘llanmasi esa amaliy o‘tishni tushuntiradi. Belgilangan major release yoki support muddati tugaganda eski yo‘l olib tashlanishi mumkin.
Security talab ba’zan compatibilitydan ustun keladi: zaif protokol, cipher yoki autentifikatsiya usuli tezroq o‘chiriladi. Bunday qaror aniq risk, deadline va monitoring bilan e’lon qilinadi.
Moslik va aynan bir xil natija tushunchalari ham farqlanadi. Yangi implementatsiya ichki algoritmni almashtirib, public shartnomani saqlashi mumkin; bitma-bit natija faqat format yoki reproducibility shartnomasida talab etiladi.
Bog‘liq tushunchalar
Forward compatibility, API, ABI, Schema evolution, Breaking change, Deprecation, Rolling deployment