این بخش مفهوم ویژگی‌های آزمایشی (experimental features) را شرح می‌دهد و توضیح می‌دهد که چگونه در تصویر کلی توسعه Nix جای می‌گیرند.

13.10. ویژگی‌های آزمایشی

ویژگی‌های آزمایشی ناپایدار در نظر گرفته می‌شوند، به این معنی که ممکن است در هر زمانی تغییر کنند یا حذف شوند. کاربران باید با فعال کردن پرچم‌های ویژگی آزمایشی مرتبط، آن‌ها را به طور صریح فعال کنند. این کار اجازه می‌دهد تا بدون اتکای ناخواسته به قابلیت‌های ناپایدار، به آن‌ها دسترسی پیدا کنید.

پرچم‌های ویژگی آزمایشی برای اولین بار در Nix 2.4 معرفی شدند. پیش از آن، Nix ویژگی‌های آزمایشی داشت، اما توسط پرچم‌ها محافظت نمی‌شدند و صرفاً به عنوان ناپایدار مستند شده بودند. این موضوع منبع سردرگمی و بحث‌برانگیز بود.

چه زمانی یک ویژگی جدید باید به عنوان آزمایشی علامت‌گذاری شود؟

یک تغییر در پایگاه کد Nix باید توسط یک پرچم ویژگی آزمایشی محافظت شود، اگر این احتمال وجود داشته باشد که پس از کسب تجربه بیشتر در عمل، به شکلی ناسازگار با نسخه‌های قبلی (backwards-incompatible) برگردانده یا سازگار شود.

مثال‌ها:

تغییرات در زبان Nix، مانند توابع داخلی جدید، تغییرات نحوی یا معنایی و غیره.
تغییرات در رابط خط فرمان

چرخه حیات یک ویژگی آزمایشی

با ویژگی‌های آزمایشی باید موردمورده (case-by-case) برخورد شود. با این حال، روند استاندارد برای یک ویژگی آزمایشی به شرح زیر است:

یک ویژگی جدید در یک پول ریکوئست (pull request) پیاده‌سازی می‌شود
- این ویژگی توسط یک پرچم ویژگی آزمایشی که به‌طور پیش‌فرض غیرفعال است، محافظت می‌شود
پول ریکوئست ادغام می‌شود، و ویژگی آزمایشی در یک نسخه منتشرشده قرار می‌گیرد
- استفاده از این ویژگی مستلزم فعال‌سازی صریح آن است که نشان‌دهنده آگاهی از خطرات احتمالی است
- از آنجایی که این ویژگی آزمایشی است، همچنان می‌تواند به دلخواه تغییر کند
این ویژگی می‌تواند حذف شود
- پرچم ویژگی آزمایشی مرتبط نیز حذف می‌شود
این ویژگی می‌تواند به عنوان پایدار اعلام شود
- پرچم ویژگی آزمایشی مرتبط حذف می‌شود
- باید شواهد کافی از امتحان کردن این ویژگی توسط کاربران وجود داشته باشد، مانند بازخوردها، اشکالات برطرف‌شده، و نمونه‌هایی از نحوه به‌کارگیری آن
- نگه‌دارندگان باید اطمینان حاصل کنند که:
  - این ویژگی به صورت عاقلانه‌ای طراحی و پیاده‌سازی شده است و برای هدف خود مناسب است
  - تداخل‌های احتمالی به خوبی درک شده‌اند
  - پایدارسازی این ویژگی در آینده بار نگهداری بیش از حدری ایجاد نخواهد کرد

نمودار زیر این فرآیند را نشان می‌دهد:

                  .------.
                  | idea |
                  '------'
                      |
       discussion, design, implementation
                      |
                      |     .-------.
                      |     |       |
                      v     v       |
               .--------------.  review
               | pull request |     |
               '--------------'     |
                   |     ^  |       |
                   |     |  '-------'
               .---'     '----.
               |              |
             merge       user feedback,
               |       (breaking) changes
               |              |
               '---.     .----'
                   |     |
                   v     |
               +--------------+
           .---| experimental |----.
           |   +--------------+    |
           |                       |
decision to stabilise      decision against
           |              keeping the feature
           |                       |
           v                       v
       +--------+             +---------+
       | stable |             | removed |
       +--------+             +---------+

ارتباط با فرآیند RFC

ویژگی‌های آزمایشی و RFCها هر دو امکان نزدیک شدن به تغییرات اساسی را در عین به حداقل رساندن مخاطرات فراهم می‌کنند. با این حال، اهداف متفاوتی را دنبال می‌کنند:

یک ویژگی آزمایشی به توسعه‌دهندگان اجازه می‌دهد تا بدون تعهد بلندمدت یا نیاز به انشعاب (fork) پرهزینه و طولانی‌مدت، روی یک ایده جدید کار کرده و آن را پیاده‌سازی و ارائه کنند. این موضوع اساساً مربوط به پیاده‌سازی است و توسعه‌دهندگان Nix و آزمایش‌کنندگان اولیه را هدف قرار می‌دهد.
هدف یک RFC این است که تمام پیامدهای یک تغییر را به صراحت بیان کند: توضیح دهد که چرا این تغییر مورد نیاز است، چه موارد استفاده جدیدی را امکان‌پذیر می‌سازد، چه تغییراتی در رابط کاربری یا رابط‌های دیگر نیاز دارد، و غیره. این موضوع اساساً مربوط به طراحی و ارتباطات است و جامعه‌ی کاربری وسیع‌تر را هدف قرار می‌دهد.

این بدان معناست که ویژگی‌های آزمایشی و RFCها مکانیسم‌هایی مستقل از یکدیگر (orthogonal) هستند و می‌توانند بر حسب نیاز به صورت مستقل یا در کنار یکدیگر استفاده شوند.

ویژگی‌های آزمایشی در حال حاضر

nix.dev/manual/nix/stable/development/experimental-features.html