الملحق ز - كيف تُصنع Rust و “نسخة نايتلي” (Appendix G - How Rust is Made and “Nightly Rust”)
يدور هذا الملحق حول كيفية صنع لغة Rust وكيف يؤثر ذلك عليك كمطور Rust.
الاستقرار بدون ركود (Stability Without Stagnation)
كلغة برمجة، تهتم Rust كثيرًا باستقرار الكود الخاص بك. نريد أن تكون Rust أساسًا صلبًا يمكنك البناء عليه، وإذا كانت الأشياء تتغير باستمرار، فسيكون ذلك مستحيلاً. في الوقت نفسه، إذا لم نتمكن من تجربة ميزات جديدة، فقد لا نكتشف العيوب المهمة إلا بعد إصدارها، عندما لا نعود قادرين على تغيير الأشياء.
حلنا لهذه المشكلة هو ما نسميه “الاستقرار بدون ركود” (stability without stagnation)، ومبدأنا التوجيهي هو التالي: يجب ألا تضطر أبدًا إلى الخوف من الترقية إلى إصدار جديد من Rust المستقر (stable). يجب أن تكون كل ترقية غير مؤلمة، ولكن يجب أيضًا أن تجلب لك ميزات جديدة، وأخطاء أقل، وأوقات ترجمة (compile times) أسرع.
تشو، تشو! قنوات الإصدار وركوب القطارات (Choo, Choo! Release Channels and Riding the Trains)
يعمل تطوير Rust وفقًا لـ جدول قطار (train schedule). أي أن كل التطوير يتم في الفرع الرئيسي (main branch) لمستودع Rust. تتبع الإصدارات نموذج قطار إصدار البرمجيات (software release train model)، والذي تم استخدامه بواسطة Cisco IOS ومشاريع برمجية أخرى. هناك ثلاث قنوات إصدار (release channels) لـ Rust:
- نايتلي (Nightly)
- بيتا (Beta)
- مستقر (Stable)
يستخدم معظم مطوري Rust قناة Stable بشكل أساسي، ولكن أولئك الذين يرغبون في تجربة ميزات جديدة تجريبية قد يستخدمون Nightly أو Beta.
إليك مثال على كيفية عمل عملية التطوير والإصدار: لنفترض أن فريق Rust يعمل على إصدار Rust 1.5. حدث ذلك الإصدار في ديسمبر من عام 2015، ولكنه سيوفر لنا أرقام إصدارات واقعية. تمت إضافة ميزة جديدة إلى Rust: وصل التزام (commit) جديد إلى الفرع الرئيسي. في كل ليلة، يتم إنتاج نسخة Nightly جديدة من Rust. كل يوم هو يوم إصدار، ويتم إنشاء هذه الإصدارات بواسطة بنية الإصدار التحتية (release infrastructure) الخاصة بنا تلقائيًا. لذا مع مرور الوقت، تبدو إصداراتنا هكذا، مرة واحدة كل ليلة:
nightly: * - - * - - *
كل ستة أسابيع، يحين وقت إعداد إصدار جديد! يتفرع فرع beta لمستودع Rust من الفرع الرئيسي المستخدم بواسطة Nightly. الآن، هناك إصداران:
nightly: * - - * - - *
|
beta: *
لا يستخدم معظم مستخدمي Rust إصدارات Beta بنشاط، ولكنهم يختبرون مقابل Beta في نظام التكامل المستمر (CI system) الخاص بهم لمساعدة Rust في اكتشاف التراجعات (regressions) المحتملة. في هذه الأثناء، لا يزال هناك إصدار Nightly كل ليلة:
nightly: * - - * - - * - - * - - *
|
beta: *
لنفترض أنه تم العثور على تراجع (regression). من الجيد أننا حصلنا على بعض الوقت لاختبار إصدار Beta قبل أن يتسلل التراجع إلى إصدار Stable! يتم تطبيق الإصلاح على الفرع الرئيسي، بحيث يتم إصلاح Nightly، ثم يتم نقل الإصلاح (backported) إلى فرع beta ويتم إنتاج إصدار جديد من Beta:
nightly: * - - * - - * - - * - - * - - *
|
beta: * - - - - - - - - *
بعد ستة أسابيع من إنشاء أول نسخة Beta، يحين وقت إصدار Stable! يتم إنتاج فرع stable من فرع beta:
nightly: * - - * - - * - - * - - * - - * - * - *
|
beta: * - - - - - - - - *
|
stable: *
هيا! لقد انتهى Rust 1.5! ومع ذلك، فقد نسينا شيئًا واحدًا: نظرًا لمرور الأسابيع الستة، نحتاج أيضًا إلى نسخة Beta جديدة من الإصدار التالي من Rust، وهو 1.6. لذا بعد أن يتفرع stable من beta يتفرع الإصدار التالي من beta من nightly مرة أخرى:
nightly: * - - * - - * - - * - - * - - * - * - *
| |
beta: * - - - - - - - - * *
|
stable: *
يسمى هذا “نموذج القطار” (train model) لأنه كل ستة أسابيع، يغادر إصدار “المحطة”، ولكن لا يزال يتعين عليه القيام برحلة عبر قناة Beta قبل أن يصل كإصدار Stable.
تصدر Rust إصدارات كل ستة أسابيع، مثل الساعة. إذا كنت تعرف تاريخ إصدار واحد لـ Rust، فيمكنك معرفة تاريخ الإصدار التالي: إنه بعد ستة أسابيع. الجانب الجيد في وجود إصدارات مجدولة كل ستة أسابيع هو أن القطار التالي قادم قريبًا. إذا حدث أن فاتت ميزة معينة إصدارًا معينًا، فلا داعي للقلق: فهناك إصدار آخر سيحدث في وقت قصير! يساعد هذا في تقليل الضغط للتسلل بميزات قد لا تكون مصقولة بالقرب من الموعد النهائي للإصدار.
بفضل هذه العملية، يمكنك دائمًا التحقق من البناء التالي لـ Rust والتحقق بنفسك من سهولة الترقية إليه: إذا لم يعمل إصدار Beta كما هو متوقع، يمكنك إبلاغ الفريق به وإصلاحه قبل حدوث إصدار Stable التالي! الكسر (Breakage) في إصدار Beta نادر نسبيًا، ولكن rustc لا يزال قطعة من البرمجيات، والأخطاء موجودة.
وقت الصيانة (Maintenance time)
يدعم مشروع Rust أحدث إصدار مستقر. عندما يتم إصدار نسخة مستقرة جديدة، يصل الإصدار القديم إلى نهاية عمره (EOL). هذا يعني أن كل إصدار يتم دعمه لمدة ستة أسابيع.
الميزات غير المستقرة (Unstable Features)
هناك عقبة أخرى في نموذج الإصدار هذا: الميزات غير المستقرة (unstable features). تستخدم Rust تقنية تسمى “أعلام الميزات” (feature flags) لتحديد الميزات التي يتم تمكينها في إصدار معين. إذا كانت ميزة جديدة قيد التطوير النشط، فإنها تصل إلى الفرع الرئيسي، وبالتالي في Nightly، ولكن خلف علم ميزة (feature flag). إذا كنت ترغب، كمستخدم، في تجربة الميزة التي لا تزال قيد العمل، يمكنك ذلك، ولكن يجب أن تستخدم إصدار Nightly من Rust وتضع علامة على كود المصدر الخاص بك بالعلم المناسب للاشتراك.
إذا كنت تستخدم إصدار Beta أو Stable من Rust، فلا يمكنك استخدام أي أعلام ميزات. هذا هو المفتاح الذي يسمح لنا بالحصول على استخدام عملي للميزات الجديدة قبل أن نعلن استقرارها للأبد. أولئك الذين يرغبون في الاشتراك في أحدث التقنيات (bleeding edge) يمكنهم فعل ذلك، وأولئك الذين يريدون تجربة صلبة كالصخر يمكنهم الالتزام بـ Stable ومعرفة أن كودهم لن ينكسر. الاستقرار بدون ركود.
يحتوي هذا الكتاب فقط على معلومات حول الميزات المستقرة، حيث أن الميزات قيد العمل لا تزال تتغير، وبالتأكيد ستكون مختلفة بين وقت كتابة هذا الكتاب ووقت تمكينها في البناءات المستقرة. يمكنك العثور على وثائق للميزات الخاصة بـ Nightly فقط عبر الإنترنت.
Rustup ودور نسخة نايتلي (Rustup and the Role of Rust Nightly)
يجعل Rustup من السهل التغيير بين قنوات الإصدار المختلفة لـ Rust، على أساس عالمي أو لكل مشروع. بشكل افتراضي، سيكون لديك Rust المستقر مثبتًا. لتثبيت Nightly، على سبيل المثال:
$ rustup toolchain install nightly
يمكنك رؤية جميع سلاسل الأدوات (toolchains) (إصدارات Rust والمكونات المرتبطة بها) التي قمت بتثبيتها باستخدام rustup أيضًا. إليك مثال على كمبيوتر يعمل بنظام Windows لأحد المؤلفين:
> rustup toolchain list
stable-x86_64-pc-windows-msvc (default)
beta-x86_64-pc-windows-msvc
nightly-x86_64-pc-windows-msvc
كما ترى، فإن سلسلة أدوات Stable هي الافتراضية. يستخدم معظم مستخدمي Rust نسخة Stable معظم الوقت. قد ترغب في استخدام Stable معظم الوقت، ولكن تستخدم Nightly في مشروع معين، لأنك تهتم بميزة متطورة. للقيام بذلك، يمكنك استخدام rustup override في دليل ذلك المشروع لتعيين سلسلة أدوات Nightly لتكون هي التي يجب أن يستخدمها rustup عندما تكون في ذلك الدليل:
$ cd ~/projects/needs-nightly
$ rustup override set nightly
الآن، في كل مرة تستدعي فيها rustc أو cargo داخل دليل ~/projects/needs-nightly، سيتأكد rustup من أنك تستخدم Nightly Rust، بدلاً من Rust المستقر الافتراضي لديك. هذا مفيد جدًا عندما يكون لديك الكثير من مشاريع Rust!
عملية RFC والفرق (The RFC Process and Teams)
إذًا كيف تتعلم عن هذه الميزات الجديدة؟ يتبع نموذج تطوير Rust عملية طلب التعليقات (RFC) (Request For Comments process). إذا كنت ترغب في تحسين في Rust، يمكنك كتابة اقتراح يسمى RFC.
يمكن لأي شخص كتابة RFCs لتحسين Rust، ويتم مراجعة الاقتراحات ومناقشتها من قبل فريق Rust، الذي يتكون من العديد من الفرق الفرعية للموضوعات. هناك قائمة كاملة بالفرق على موقع Rust الإلكتروني، والتي تتضمن فرقًا لكل منطقة من مناطق المشروع: تصميم اللغة، تنفيذ المترجم، البنية التحتية، التوثيق، والمزيد. يقرأ الفريق المناسب الاقتراح والتعليقات، ويكتب بعض التعليقات الخاصة به، وفي النهاية، يكون هناك إجماع على قبول الميزة أو رفضها.
إذا تم قبول الميزة، يتم فتح مشكلة (issue) في مستودع Rust، ويمكن لشخص ما تنفيذها. الشخص الذي ينفذها قد لا يكون هو الشخص الذي اقترح الميزة في المقام الأول! عندما يكون التنفيذ جاهزًا، فإنه يصل إلى الفرع الرئيسي خلف بوابة ميزة (feature gate)، كما ناقشنا في قسم “الميزات غير المستقرة”.
بعد مرور بعض الوقت، وبمجرد أن يتمكن مطورو Rust الذين يستخدمون إصدارات Nightly من تجربة الميزة الجديدة، سيناقش أعضاء الفريق الميزة، وكيف سارت الأمور في Nightly، ويقررون ما إذا كان ينبغي أن تصل إلى Rust المستقر أم لا. إذا كان القرار هو المضي قدمًا، يتم إزالة بوابة الميزة، وتعتبر الميزة الآن مستقرة! تركب القطارات إلى إصدار مستقر جديد من Rust.