Breaking change — yangi versiyadagi o‘zgarish avvalgi public shartnomaga mos keladigan iste’molchi, ma’lumot yoki integratsiyaning endi to‘g‘ri ishlamasligiga sabab bo‘ladigan o‘zgarishdir. Funksiyani olib tashlash uning aniq misoli, ammo parametr ma’nosi, xato turi, serialization formati, default qiymat yoki performance xususiyatini o‘zgartirish ham iste’molchi shu xulqqa tayangan bo‘lsa breaking bo‘lishi mumkin.
Shartnoma turlari
Source breaking change eski kodning yangi API bilan kompilyatsiya qilinmasligiga olib keladi. Binary break oldin kompilyatsiya qilingan artefaktning yangi kutubxona ABI bilan yuklanmasligi yoki noto‘g‘ri ishlashidir. Wire protocol va database schema o‘zgarishi turli versiyadagi servislar o‘rtasini buzishi mumkin.
Behavioral break sintaktik interfeys o‘zgarmasa ham natijani o‘zgartiradi. Masalan, ro‘yxat ilgari insertion orderda qaytib, yangi release’da tartib kafolatsiz bo‘lsa, hujjatlangan orderga tayangan mijoz buziladi. Hujjatlanmagan, lekin keng kuzatilgan xulqni o‘zgartirish ham amaliy xavfga ega.
Aniqlash
API diff vositasi export qilingan symbol, signature va type o‘zgarishini topadi. ABI checker struct layout, vtable va calling convention farqini ko‘radi. Schema compatibility checker maydon ID, required holat va tur evolyutsiyasini tekshiradi. Bular semantic va behavioral ta’sirni to‘liq tushunmaydi, shuning uchun contract test va review kerak.
Consumer-driven contract real iste’molchilarning talabini provider pipeline’da tekshiradi. Telemetry ishlatilayotgan endpoint, parameter va client versiyalarini ko‘rsatadi. Biroq kuzatilmagan offline mijoz yoki kam ishlatiladigan qonuniy integratsiya mavjud bo‘lishi mumkin; support policy chegarani belgilaydi.
Boshqariladigan migratsiya
Breaking o‘zgarish zarur bo‘lsa, eski va yangi yo‘l bir muddat yonma-yon ishlaydi. Deprecation warning muqobil API va olib tashlash muddatini beradi. Migration guide oldin-keyin namunasi, data transform va rollbackni tushuntiradi. Semantic Versioning ishlatilsa, incompatible public API odatda MAJOR versiyani oshiradi.
Distributed tizimda expand-and-contract usuli qo‘llanadi. Avval yangi schema qo‘shilib, eski kod bilan mos ishlaydi. Keyin producer va consumerlar yangi formatga o‘tadi. Oxirida foydalanilmayotgan eski ustun yoki maydon olib tashlanadi. Bitta deployda rename qilish rolling update va rollbackni buzishi mumkin.
Versiyalangan interfeys
HTTP API path, media type yoki header orqali versiyalanishi mumkin. Versiyalash eski mijozga vaqt beradi, lekin har versiya security patch, monitoring va operatsion xarajat talab qiladi. Bir xil backendda ko‘p eski semantika uzoq saqlansa, test kombinatsiyalari keskin ko‘payadi.
Feature flag yangi xulqni canary guruhga yoqishga yordam beradi. Flag compatibility shartnomasini almashtirmaydi; u rollout va rollback vositasidir. Yangi format bilan yozilgan ma’lumot eski kodga qaytarilganda nima bo‘lishi alohida tekshiriladi.
Zarur tezkor uzilishlar
Zaif autentifikatsiya usuli yoki xavfli protocolni saqlash foydalanuvchini himoyasiz qoldirishi mumkin. Security emergencyda odatdagi deprecation oynasi qisqaradi. Qaror ta’sir, aniq deadline, aniqlash metrikasi va yordam kanali bilan e’lon qilinadi. “Xavfsizlik” belgisi har qanday rejasiz breakni oqlamaydi; imkon bo‘lsa compatibility shim va avtomatik migratsiya beriladi.
Hujjat va egalik
Har breaking change uchun qaror egasi, ta’sirlangan iste’molchilar, migratsiya muddati va muvaffaqiyat mezoni belgilanadi. Release note faqat “API yangilandi” demaydi; o‘zgargan shartnoma, replacement va ishlaydigan misolni ko‘rsatadi.
Eski yo‘lni olib tashlashdan oldin foydalanish telemetrysi tekshiriladi. Telemetry yo‘qligi foydalanish yo‘qligini isbotlamaydi, ayniqsa self-hosted va offline iste’molchilarda; e’lon qilingan support policy yakuniy chegarani beradi.
Bog‘liq tushunchalar
Backward compatibility, Semantic Versioning, Deprecation, API versioning, Schema migration, Contract testing, Major release