حاکمیت نسخه‌بندی و قابلیت‌ها

این صفحه خلاصه مدل رسمی حاکمیت BDL برای نسخه‌بندی، سازگاری و ادعاهای مربوط به قابلیت‌ها است.

حوزه‌های نسخه

BDL چند حوزه نسخه مستقل دارد و نسخه یک حوزه نباید نسخه حوزه دیگر تلقی شود.

حوزه	خط مبنای رسمی فعلی
زبان و مدل دانشی BDL	5.2.2
قرارداد Native Barsa	2.0.0
Runtime / Troubleshooting	2.0.0
سطح Authoring BDL	خط مبنای مستقل فعلی هنوز Freeze نشده است
سایت مستندات	v1.1.0
Source Registry	1.0

یکسان بودن شماره نسخه‌ها در دو حوزه، به‌تنهایی به معنی سازگاری نیست.

مدل نسخه BDL

نسخه زبان BDL از قالب زیر استفاده می‌کند:

MAJOR.MINOR.PATCH

• MAJOR — تغییر معنایی ناسازگار و Breaking.
• MINOR — توسعه معنایی سازگار با نسخه‌های قبلی.
• PATCH — اصلاح سازگار یا شفاف‌سازی بدون تغییر اساسی قرارداد زبان.

نسخه منتشرشده و Governed از BDL از نظر معنایی immutable است و تغییر معنایی باید نسخه جدید دریافت کند.

خط مبنای رسمی فعلی BDL نسخه 5.2.2 است.

سازگاری جهت‌دار است

هر ادعای سازگاری باید Subject، Target، Direction، Scope، Result، Evidence و Provenance مشخص داشته باشد.

Backward Compatibility توان نسخه جدیدتر برای کار صحیح با هدف قدیمی‌تر را بررسی می‌کند.

Forward Compatibility توان نسخه قدیمی‌تر برای تحمل یا تعامل صحیح با هدف جدیدتر را بررسی می‌کند.

Bidirectional Compatibility فقط زمانی معتبر است که هر دو جهت برای Scope یکسان به‌طور مستقل اثبات شده باشند.

شماره نسخه به‌تنهایی سازگاری را اثبات نمی‌کند.

وضعیت‌های سازگاری

مقادیر رسمی عبارت‌اند از:

• compatible
• conditionally_compatible
• incompatible
• unknown
• unverified
• not_applicable

در صورت ناکافی بودن شواهد معتبر باید از unknown استفاده شود.

تغییر Breaking و Non-Breaking

رده‌های رسمی تغییر عبارت‌اند از:

• breaking
• non_breaking
• conditionally_breaking
• documentation_only
• unknown

اگر یک تغییر باعث نامعتبر شدن استفاده قبلی، تغییر ناسازگار معنا، حذف قابلیت موردنیاز یا شکست تعامل قبلاً معتبر شود، در Scope مربوطه Breaking است.

صرفاً Additive بودن یک تغییر، سازگاری آن را تضمین نمی‌کند.

Deprecation و Withdrawal

Deprecated و Withdrawn دو وضعیت متفاوت هستند.

• Deprecated — قابلیت یا مورد هنوز شناخته‌شده یا قابل استفاده است، اما استفاده جدید از آن توصیه نمی‌شود.
• Withdrawn — مورد دیگر برای استفاده جاری در Scope مربوطه تأییدشده نیست.

منابع Deprecated، Superseded، Withdrawn و Historical نباید به‌شکل پنهانی حذف شوند.

تغییر وضعیت چرخه عمر باید صریح و قابل ممیزی باشد.

چهار لایه رسمی قابلیت

هر ادعای قابلیت باید دقیقاً لایه مربوطه را مشخص کند.

۱. Native Barsa

مشخص می‌کند آیا قابلیت به‌صورت Native در برسا یا قرارداد رسمی Native آن وجود دارد.

شناسه: native_barsa

۲. Runtime Support

مشخص می‌کند آیا قابلیت در زمان اجرا و مسیر Runtime واقعاً پشتیبانی می‌شود.

شناسه: runtime_support

۳. BDL Expressibility

مشخص می‌کند آیا مدل رسمی زبان BDL امکان بیان آن قابلیت را دارد.

شناسه: bdl_expressibility

۴. BDL Authoring Availability

مشخص می‌کند آیا قابلیت از طریق سطح Authoring مربوط به BDL قابل ایجاد، انتخاب، ویرایش یا پیکربندی است.

شناسه: bdl_authoring

استقلال لایه‌ها

نتیجه مثبت در یک لایه نباید خودکار به لایه دیگری منتقل شود.

برای مثال این وضعیت کاملاً معتبر است:

Native Barsa:               available
Runtime Support:            available
BDL Expressibility:         available
BDL Authoring Availability: unavailable

این چهار نتیجه نباید به یک عبارت عمومی مانند «پشتیبانی می‌شود» تبدیل شوند.

وضعیت‌های قابلیت

مقادیر رسمی عبارت‌اند از:

• available
• partially_available
• conditionally_available
• unavailable
• unknown
• unverified
• not_applicable
• deprecated
• withdrawn

Capability State با Compatibility State متفاوت است.

برای مثال available و compatible دو گزاره متفاوت هستند.

الزامات Evidence

شواهد باید متناسب با همان لایه قابلیت باشند.

• Native Barsa به شواهد معتبر Native نیاز دارد.
• Runtime Support به شواهد اجرایی و Runtime نیاز دارد.
• BDL Expressibility به شواهد زبان، Schema یا مدل معنایی BDL نیاز دارد.
• BDL Authoring Availability به شواهد سطح Authoring نیاز دارد.

نبود Evidence به‌تنهایی اثبات unavailable نیست.

اگر Evidence کافی وجود ندارد باید از unknown یا unverified استفاده شود.

ممنوعیت استنتاج بین‌لایه‌ای

بدون Evidence مستقل، این استنتاج‌ها مجاز نیستند:

• Native Barsa → Runtime Support
• Runtime Support → Native Barsa
• BDL Expressibility → Runtime Support
• Runtime Support → BDL Expressibility
• BDL Expressibility → BDL Authoring Availability
• BDL Authoring Availability → BDL Expressibility

تفاوت لایه‌ها الزاماً تعارض نیست

نتایج متفاوت در لایه‌های مختلف می‌توانند هم‌زمان صحیح باشند.

تعارض واقعی فقط زمانی رخ می‌دهد که دو ادعا درباره همان قابلیت، همان لایه، همان نسخه یا Baseline، همان Scope و همان شرایط باشند ولی نتیجه ناسازگار بدهند.

در یک لایه و Scope یکسان، قواعد Source Precedence و Conflict Resolution اعمال می‌شوند.

هیچ‌یک از چهار لایه به‌صورت عمومی بر لایه دیگر برتری ندارد.

داده Machine-Readable

داده رسمی حاکمیت قابلیت‌ها در فایل زیر نگهداری می‌شود:

capability-governance.json

این فایل شامل لایه‌ها، وضعیت‌های قابلیت، وضعیت‌های سازگاری، Change Classها، Conflict Stateها، Version Domainها و Ruleهای اجباری است.

این داده توسط Validator پروژه اعتبارسنجی می‌شود.

ارتباط با Source of Truth

تمام ادعاهای Version، Compatibility و Capability همچنان تابع مدل Source of Truth پروژه هستند.

Authority، Provenance، Evidence، Preservation، Precedence و Conflict Resolution همچنان معتبر هستند.

همچنین ببینید: Source of Truth.