رفتن به محتوا

نسخه‌بندی و پایداری

بسته‌های Simurgh تا پیش از 1.0 پیش‌انتشار هستند. نسخهٔ دقیق را در production pin کنید و هر ارتقا را مانند یک تغییر نیازمند review در نظر بگیرید. بسته‌های هم‌نسخه مانند adapter و styles را با هم ارتقا دهید.

چه چیزی breaking محسوب می‌شود؟

Section titled “چه چیزی breaking محسوب می‌شود؟”

حذف یا تغییر prop، event، input، output، slot، export، مسیر import، token عمومی، state hook، DOM contract مستند یا رفتار صفحه‌کلید و focus یک تغییر breaking است. تغییر پیش‌فرضی که نتیجهٔ فرم، SSR یا دسترس‌پذیری را عوض کند نیز breaking محسوب می‌شود.

وقتی امکان‌پذیر باشد API قدیمی ابتدا deprecated می‌شود و راه مهاجرت در release note می‌آید. اصلاح امنیتی یا دسترس‌پذیری ممکن است نیازمند تغییر سریع‌تر باشد. Changeset و راهنمای مهاجرت منبع تصمیم ارتقا هستند.

پشتیبانی رسمی نسخه‌های فریم‌ورک در صفحهٔ سازگاری ثبت می‌شود. نسخه‌های خارج از آن ممکن است کار کنند، اما در CI تضمین نمی‌شوند.

سطح‌های آزمایشی chart و motion پیش از تثبیت ممکن است سریع‌تر تغییر کنند. آن‌ها را پشت wrapper برنامه نگه دارید و از تکیه بر جزئیات داخلی خودداری کنید.

مصرف‌کنندهٔ package اصلاحات را از طریق ارتقای نسخه دریافت می‌کند. فایل‌های node_modules را ویرایش نکنید؛ اگر مهاجرت فوری ممکن نیست روی نسخهٔ دقیق قبلی بمانید.

سورس تولیدشده با CLI متعلق به برنامه است و خودکار تغییر نمی‌کند. diff فقط تفاوت با registry را گزارش می‌دهد. اصلاحات upstream را سه‌طرفه review و با سفارشی‌سازی محلی ادغام کنید.

نسخهٔ 1.0 زمانی منتشر می‌شود که قراردادهای فریم‌ورک، دسترس‌پذیری، package integrity، مستندات و release automation معیارهای خروج ثبت‌شده را پاس کنند. وضعیت فعلی در آمادگی نسخه یک نگهداری می‌شود.

Last verified on 2026-08-13 against Simurgh registry 0.1.1.