Self-hosted Release/Support Matrix

«نسخه جدیدتر» مساوی «قابل پشتیبانی» نیست

فرض کنید مشتری self-hosted روی محصول 3.4.2 است و نسخه 3.6.0 منتشر شده. عدد بزرگ‌تر وسوسه می‌کند بگوییم «ارتقا بده»، اما ماتریس آزمایش فقط runtime و database مشخصی را پوشش می‌دهد و direct upgrade از 3.4.x به 3.6.x هرگز تست نشده است. تازه یک schema migration هم در 3.5.x اجباری بوده. در این وضعیت SemVer فقط درباره معنای تغییر نسخه نسبت به API عمومی حرف می‌زند؛ درباره stack واقعی مشتری، migration، rollback یا support window ضمانت نمی‌دهد.

هدف درس ساخت Self-hosted Release, Compatibility, Upgrade & Support Matrix v1 است: release identity، deployment fingerprint، tested compatibility، upgrade hops، migration/backup/rollback، patch eligibility و EOL باید طوری ثبت شوند که تصمیم SUPPORTED / REVIEW / UNSUPPORTED بدون حدس بازسازی شود.

مرز درس و مسیر

AGN-014 مالک release/support matrix است. AGN-013 مالک subscription/grace/dunning و AGN-015 مالک demand-gated multi-tenancy است؛ این outcomeها اینجا جذب نمی‌شوند. prerequisite سخت AGN-012 و prerequisite نرم AGN-013 است.

مسیر کار: ابتدا deployment fingerprint فعلی را ثبت کنید؛ target release و version semantics را جدا بنویسید؛ سپس tested runtime/database/schema matrix را چک کنید؛ بعد upgrade path و intermediate hopها را بررسی کنید؛ migration، backup و rollback را ببندید؛ در آخر support tier، patch eligibility، support end و EOL را از evidence تعیین کنید.

مدل ذهنی: چهار قرارداد مستقل

یک self-hosted support promise را چهار قرارداد جدا ببینید: Release Semantics، Compatibility Evidence، Upgrade/Migration Path و Support Window. اگر این چهار لایه را در یک version string فشرده کنید، auditability از بین می‌رود.

SemVer 2.0.0 می‌گوید MAJOR برای تغییر ناسازگار API، MINOR برای functionality سازگار و PATCH برای bug fix سازگار است؛ این درباره API declared است، نه تضمین سازگاری همه database/runtimeها. Kubernetes نمونه‌ی روشن‌تری از جداسازی است: علاوه بر versioning، محدودیت version skew، ترتیب upgrade و release support را جداگانه منتشر می‌کند. نتیجه‌ی طراحی MAKNOW این است که version ordering هرگز oracle سازگاری نیست.

فیلدهای پایه‌ی Matrix

هویت release با release_id, product_version, release_channel, public_api_version و target release شروع می‌شود. هویت نصب با deployment_fingerprint, runtime_version, database_version, schema_version, os_or_container_ref و dependency version ثبت می‌شود.

سازگاری باید به tested_runtime_versions, tested_database_versions, tested_matrix_id و compatibility_evidence_ref وصل باشد. مسیر ارتقا نیز جداست: upgrade_from_version, upgrade_to_version, supported_upgrade_from_versions, upgrade_hop_state, migration_required, backup_required, rollback_supported. در پایان، support policy با support_tier, patch_eligible, support_end, eol_state و security_fix_policy_ref ثبت می‌شود.

چرا SemVer، Compatibility و Support یکی نیستند؟

سه سؤال متفاوت را جدا نگه دارید: «این version label چه معنی دارد؟»، «این deployment combination واقعاً تست شده؟» و «vendor تا چه تاریخی چه نوع پشتیبانی می‌دهد؟». ممکن است 3.4.2 -> 3.6.0 از نظر نسخه‌گذاری مرتب و معقول باشد، ولی direct upgrade path پشتیبانی نشده باشد. ممکن است runtime تست شده باشد اما database minor جدید هنوز در matrix نباشد. حتی ممکن است ترکیب کاملاً compatible باشد ولی release از support window خارج شده باشد.

بنابراین evaluator ابتدا fingerprint را به tested matrix وصل می‌کند، بعد upgrade hops و migration prerequisites را می‌سنجد و تازه سپس support tier/patch eligibility را می‌بندد. اگر یک حلقه decisive ناشناخته باشد، state مثبت ساخته نمی‌شود.

مثال پایه: intermediate hop اجباری

نصب A روی 3.4.2، runtime 8.0.8، database 14.9 و schema 42 است. target 3.6.0 همین runtime/database family را در matrix تست کرده، اما direct upgrade از 3.4.x مجاز نیست؛ مسیر رسمی 3.4.2 -> 3.5.4 -> 3.6.0 است و hop میانی migration ثبت‌شده می‌خواهد. backup evidence و rollback plan هم حاضرند.

پس تصمیم صحیح «latest را نصب کن» نیست؛ SUPPORTED_UPGRADE_WITH_INTERMEDIATE_HOP است و فقط چون tested matrix، hop، migration، backup و rollback با هم بسته‌اند به UPGRADE_PATH_REVIEW_READY می‌رسد.

Mutation: database را به 15.1 تغییر دهید ولی compatibility را TESTED_SUPPORTED نگه دارید. اگر 15.1 داخل tested_database_versions نیست، evaluator باید HOLD_DATABASE_VERSION_UNTESTED بدهد؛ برچسب SUPPORTED بدون evidence هیچ authority ندارد.

Failure modeهای کلیدی

1. Latest = compatible: ترتیب نسخه فقط precedence است؛ compatibility test نیست.
2. PATCH = safe everywhere: patch semantics هم نیاز به deployment compatibility دارد.
3. Direct hop by arithmetic: عبور از 3.4 به 3.6 ممکن است migration میانی را دور بزند.
4. Migration بدون backup: recovery boundary ناقص است.
5. Rollback=true بدون plan/ref: assertion بدون evidence.
6. Support tier بدون support_end: entitlement زمانی قابل audit نیست.
7. EOL ولی patch_eligible=true: policy conflict مگر استثنای صریح و traceable وجود داشته باشد.
8. Compatibility range مبهم: بازه نوشته‌شده بدون tested matrix authority کافی ندارد.

سه تصمیم ممکن: Upgrade، Stay یا Patch-only

UPGRADE وقتی مناسب است که target combination تست شده و path کامل باشد. STAY می‌تواند تصمیم درست باشد اگر release فعلی هنوز پشتیبانی دارد و upgrade prerequisites کامل نیستند. PATCH_ONLY برای security fix بدون feature upgrade فقط زمانی معتبر است که release/tier patch-eligible باشد و deployment combination هم در support boundary قرار گیرد.

این درس «ارتقا دادن» را موفقیت فرض نمی‌کند. موفقیت یعنی support decision bounded و reproducible. گاهی HOLD یا STAY از upgrade بی‌مدرک حرفه‌ای‌تر است.

برای مهندس باتجربه: Matrix را executable کنید

اگر SemVer و release pipelines را می‌شناسید، تمرکز روی consistency ruleهاست. هر release باید یک matrix row قابل ماشین‌خواندن داشته باشد. evaluator باید بتواند mutationهای کوچک را تشخیص دهد: database minor عوض شود، support_end بگذرد، hop حذف شود، migration ref پاک شود یا rollback assertion بدون ref بماند.

مهم‌تر: compatibility_state=TESTED_SUPPORTED نباید یک label آزاد باشد؛ باید با exact tested versions و evidence ref سازگار باشد. در غیر این صورت Matrix خودش به منبع false confidence تبدیل می‌شود.

تمرین هدایت‌شده و مستقل

ابتدا baseline را اجرا کنید و نشان دهید چرا direct upgrade رد می‌شود ولی intermediate path review-ready است. بعد database را به نسخه‌ی تست‌نشده ببرید و بدون تغییر label سازگاری، gate را اجرا کنید. در تمرین مستقل، migration ref یا backup evidence را حذف کنید و ببینید کدام blocker فعال می‌شود.

سپس transfer را اجرا کنید: نصب دوم containerized است، runtime پشتیبانی‌شده دارد، اما database minor جدید هنوز تست نشده و فقط security patch می‌خواهد. تصمیم baseline را کپی نکنید؛ patch eligibility را از support tier + deployment compatibility دوباره محاسبه کنید.

چه چیزی باید قابل بازسازی باشد؟

Reviewer باید بتواند از روی package پاسخ دهد: release فعلی و target چیست؟ fingerprint دقیق نصب چیست؟ runtime/database/schema داخل کدام tested matrix هستند؟ direct یا intermediate hop کدام است؟ migration/backup/rollback refs کجاست؟ support tier و support_end چه هستند؟ patch policy چیست؟ known incompatibility ثبت شده؟ operator چه چیزی را acknowledge کرده و audit ref کدام است؟

اگر جواب یکی از این‌ها فقط «چون version جدیدتر است» باشد، evidence کافی نیست.

Assessment و Transfer

سناریوی transfer عمداً tricky است: runtime پشتیبانی می‌شود و درخواست فقط security patch است، ولی database minor جدید داخل tested matrix نیست. اینجا PATCH نباید به‌خاطر «minor جدیدتر» خودکار eligible شود. evaluator باید compatibility را دوباره بسنجد و تا زمان وجود evidence، HOLD_PATCH_ON_UNTESTED_DATABASE بدهد.

اگر بعداً tested evidence برای همان database minor اضافه شود و support tier هنوز security fixes را پوشش دهد، همان fixture با recomputation می‌تواند به PATCH_REVIEW_READY برسد. تغییر evidence باید نتیجه را عوض کند؛ baseline oracle نباید تصمیم را ثابت نگه دارد.

Fact / Inference / Design و تازگی

FACT: SemVer 2.0.0 معنی MAJOR/MINOR/PATCH را نسبت به public API تعریف می‌کند. FACT: Kubernetes version-skew و maintained release branches/support window را مستقل و صریح منتشر می‌کند. INFERENCE: جداکردن release semantics، tested compatibility، upgrade path و support window auditability را بالا می‌برد. DESIGN: support tier، compatibility ranges، patch eligibility، migration policy و EOL policy متعلق به MAKNOW/product owner است.

SemVer منبع بنیادی پایدار است. سیاست‌های Kubernetes practice-evolving هستند و حداکثر تا 2027-01-01 یا زودتر در صورت تغییر material recheck می‌شوند. هیچ‌کدام authority خودکار برای policy داخلی MAKNOW نیستند.