معلومات المسؤول
=================

الإصدار
-------

يتعلق هذا القسم بإعداد إصدار رئيسي/ثانوي، أو إصدار مرشح (RC)، أو إصدار إصلاح الأخطاء. نتبع `PEP440 <https://www.python.org/dev/peps/pep-0440/>`_
لمخطط الإصدار وللإشارة إلى أنواع مختلفة من الإصدارات. اتفاقيتنا هي
اتباع مخطط "major.minor.micro"، على الرغم من أنه في الممارسة العملية لا يوجد فرق أساسي
بين الإصدارات الرئيسية والثانوية والإصدارات الصغيرة هي إصدارات إصلاح الأخطاء.

اعتمدنا الجدول الزمني للإصدار التالي:

- الإصدارات الرئيسية/الثانوية كل 6 أشهر، عادة في شهري مايو ونوفمبر. يتم ترقيم هذه الإصدارات
  `X.Y.0` ويسبقها إصدار مرشح واحد أو أكثر `X.Y.0rcN`.
- يتم إجراء إصدارات إصلاح الأخطاء حسب الحاجة بين الإصدارات الرئيسية/الثانوية وتنطبق فقط على
  أحدث إصدار مستقر. يتم ترقيم هذه الإصدارات `X.Y.Z`.

.. rubric:: التحضير

- تأكد من حل جميع العوائق التي تم وضع علامة عليها للميل، وأن القضايا الأخرى التي تم وضع علامة عليها للميل
  يمكن تأجيلها.

- تأكد من العناية بالتقادم وFIXMEs وTODOs التي تم وضع علامة عليها للإصدار.

- بالنسبة للإصدارات النهائية الرئيسية/الثانوية، تأكد من أن صفحة *Release Highlights* قد تم
  تم ذلك كمثال قابل للتنفيذ وتحقق من أن عرض HTML الخاص به يبدو صحيحًا. يجب
  أن يتم ربطه من ملف "ما الجديد" لإصدار scikit-learn الجديد.

- تأكد من أن سجل التغييرات والالتزامات تتوافق، وأن سجل التغييرات منظم بشكل معقول. على وجه الخصوص،
  تأكد من أن إدخالات سجل التغييرات تحمل علامات ومصنفة داخل كل قسم. يجب أن يكون ترتيب العلامات
  `|MajorFeature|`, `|Feature|`, `|Efficiency|`, `|Enhancement|`, `|Fix|`, و `|API|`.

.. rubric:: الأذونات

- يجب أن يكون مدير الإصدار **مسؤولاً** عن مستودع
  https://github.com/scikit-learn/scikit-learn ليكون قادرًا على النشر على
  `pypi.org` و `test.pypi.org` (عبر تشغيل يدوي لتدفق عمل GitHub Actions مخصص).

- يجب أن يكون مدير الإصدار **مسؤولاً** عن مستودع
  https://github.com/conda-forge/scikit-learn-feedstock ليكون قادرًا على النشر
  على `conda-forge`. يمكن تغيير هذا عن طريق تحرير ملف `recipe/meta.yaml` في
  طلب السحب الأول للإصدار.

خطوات مرجعية
^^^^^^^^^^^^^^^

.. tab-set::

  .. tab-item:: Major/Minor RC
    :class-label: tab-4

    لنفترض أننا نقوم بإعداد الإصدار `1.6.0rc1`.

    
    يعد أول إصدار مرشح مثاليًا بمثابة تجميد للميزات. يجب أن يتضمن كل إصدار مرشح قادم
    والإصدار النهائي التالي فقط تغييرات طفيفة في الوثائق وإصلاحات الأخطاء. يجب استبعاد أي ميزة أو ميزة جديدة رئيسية.

    - قم بإنشاء فرع الإصدار `1.6.X` مباشرة في المستودع الرئيسي،
      حيث `X` هو حرف X بالفعل، **ليس بديلاً**. يجب أن يحدث التطوير للإصدار النهائي
      والإصدارات اللاحقة لإصلاح الأخطاء من `1.6` تحت هذا الفرع أيضًا
      مع علامات مختلفة.

      .. prompt:: bash

        git checkout upstream/main
        git checkout -b 1.6.X
        git push --set-upstream upstream 1.6.X
    

    - قم بإنشاء PR من الفرع `main` الذي يستهدف فرع `1.6.X`.
      قم بنسخ قائمة التحقق من الإصدار هذه إلى وصف هذا PR لتتبع
      التقدم.

      .. code-block:: markdown

        * [ ] تحديث الأخبار وتاريخ "ما الجديد" في فرع الإصدار
        * [ ] التراجع عن الأخبار وتاريخ "ما الجديد" في فرع الإصدار
        * [ ] تحديث إصدار sklearn dev0 في فرع main
        * [ ] تعيين رقم الإصدار في فرع الإصدار
        * [ ] تأكد من أنه يمكن بناء العجلات للإصدار بنجاح
        * [ ] دمج PR مع علامة الالتزام `[cd build]` لتحميل العجلات إلى المستودع المرحلي
        * [ ] تحميل العجلات وحزمة المصدر إلى https://test.pypi.org
        * [ ] تحميل العجلات وحزمة المصدر إلى https://pypi.org
        * [ ] تأكيد على قائمة البريد الإلكتروني وعلى تويتر، وعلى LinkedIn

    

    
    - قم بإنشاء PR من `main` واستهدف `main` لزيادة متغير `__version__`
      متغير في `sklearn/__init__.py`. هذا يعني أنه أثناء فترة الإصدار
      المرشح، أحدث إصدار مستقر متأخر بمقدار نسختين عن فرع `main`،
      بدلاً من واحد. في هذا PR الذي يستهدف `main`، يجب عليك أيضًا تضمين ملف "ما الجديد" الجديد
      حتى تتمكن PRs التي تستهدف الإصدار التالي من المساهمة في إدخالات سجل التغييرات الخاصة بها في هذا الملف
      بالتوازي مع عملية الإصدار.
    

    - في فرع `1.6`.X`، قم بتغيير رقم الإصدار `__version__` في
      `sklearn/__init__.py` إلى `1.6.0rc1`.

    

    - قم بتشغيل أداة بناء العجلة مع علامة الالتزام `[cd build]`. راجع أيضًا
      `تشغيل سير عمل أداة بناء العجلة
      <https://github.com/scikit-learn/scikit-learn/actions/workflows/wheels.yml>`_.

      .. prompt:: bash

        git commit --allow-empty -m "[cd build] Trigger wheel builder workflow"

      .. note::

        يرمز الاختصار CD في `[cd build]` إلى `Continuous Delivery
        <https://en.wikipedia.org/wiki/Continuous_delivery>`_ ويشير إلى
        الأتمتة المستخدمة لتوليد عناصر الإصدار (الحزم الثنائية والمصدر)
        . يمكن اعتبار هذا امتدادًا لـ CI الذي يرمز إلى `Continuous
        Integration <https://en.wikipedia.org/wiki/Continuous_integration>`_. يستخدم سير عمل CD على GitHub Actions أيضًا لإنشاء إصدارات ليلية ونشر الحزم
        لفرع التطوير من scikit-learn. راجع أيضًا :ref:`install_nightly_builds`.

    - بمجرد اكتمال جميع وظائف CD بنجاح في PR، قم بدمجها مع
      علامة `[cd build]` في رسالة الالتزام. هذه المرة سيتم
      تحميل النتائج إلى منطقة المرحلية. بعد ذلك، يجب أن تتمكن من تحميل العناصر المولدة
      (ملفات `.tar.gz` و `.whl`) إلى https://test.pypi.org/ باستخدام نموذج "تشغيل سير العمل"
      لسير عمل النشر على PyPI
      <https://github.com/scikit-learn/scikit-learn/actions/workflows/publish_pypi.yml>`_.

      .. warning::

        يجب دمج هذا PR باستخدام وضع إعادة القاعدة بدلاً من وضع السحق المعتاد
        لأننا نريد الحفاظ على التاريخ في فرع `1.6.X` قريبًا
        تاريخ فرع `main` والذي سيساعد في الإصدارات المستقبلية لإصلاح الأخطاء.

        بالإضافة إلى أنه إذا كان الالتزام الأخير، الذي يحتوي على علامة `[cd build]`، فارغًا،
        لن يتم تشغيل وظائف CD. في هذه الحالة، يمكنك دفع التزام مباشرةً بعلامة في `1.6.X`
        لتشغيلها.

    - إذا سارت الخطوات أعلاه على ما يرام، فانتقل **بحرص** لإنشاء علامة جديدة للإصدار. يجب القيام بذلك فقط عندما تكون
      متأكدًا تقريبًا من أن الإصدار جاهز، حيث يمكن أن يؤدي إضافة علامة جديدة إلى المستودع الرئيسي إلى تشغيل
      بعض العمليات الآلية.

      .. prompt:: bash

        git tag -a 1.6.0rc1  # في فرع 1.6.X
        git push git@github.com:scikit-learn/scikit-learn.git 1.6.0rc1

    - تأكد من أن البوت قد اكتشف العلامة على مستودع conda-forge feedstock
      https://github.com/conda-forge/scikit-learn-feedstock. إذا لم يكن الأمر كذلك، فتقدم بطلب سحب للإصدار،
      استهداف الفرع `rc`.

    - قم بتشغيل سير عمل النشر على PyPI
      <https://github.com/scikit-learn/scikit-learn/actions/workflows/publish_pypi.yml>`__
      مرة أخرى، ولكن هذه المرة لتحميل العناصر إلى https://pypi.org/ الحقيقي. للقيام بذلك،
      استبدل `testpypi` بـ `pypi` في نموذج "تشغيل سير العمل".

      **بدلاً من ذلك**، من الممكن جمع عجلات الحزم الثنائية المحلية وحزم المصدر وتحميلها جميعًا إلى PyPI.

      .. dropdown:: تحميل العناصر من محلي

        قم بالتحقق من علامة الإصدار وقم بتشغيل الأوامر التالية.

        .. prompt:: bash

          rm -r dist
          python -m pip install -U wheelhouse_uploader twine
          python -m wheelhouse_uploader fetch \
            --version 0.99.0rc1 --local-folder dist scikit-learn \
            https://pypi.anaconda.org/scikit-learn-wheels-staging/simple/scikit-learn/

        ستقوم هذه الأوامر بتنزيل جميع الحزم الثنائية التي تم تجميعها في `منطقة المرحلية
        على خدمة استضافة anaconda.org
        <https://anaconda.org/scikit-learn-wheels-staging/scikit-learn/files>`_ ووضعها في
        المجلد المحلي الخاص بك `./dist`. تحقق من محتويات المجلد `./dist`:
        يجب أن يحتوي على جميع العجلات إلى جانب حزمة المصدر `.tar.gz`. تأكد من عدم وجود إصدارات مطورة أو إصدارات قديمة من حزمة scikit-learn
        في هذا المجلد. قبل التحميل إلى PyPI، يمكنك اختبار التحميل إلى
        `test.pypi.org` أولاً.

        .. prompt:: bash

          twine upload --verbose --repository-url https://test.pypi.org/legacy/ dist/*

        ثم قم بتحميل كل شيء مرة واحدة إلى `pypi.org`.

        .. prompt:: bash

          twine upload dist/*

    

    
  .. tab-item:: Major/Minor Final
    :class-label: tab-4

    لنفترض أننا نقوم بإعداد الإصدار `1.6.0`.

    

    - قم بإنشاء PR من الفرع `main` الذي يستهدف فرع `1.6.X`.
      قم بنسخ قائمة التحقق من الإصدار هذه إلى وصف هذا PR لتتبع
      التقدم.

      .. code-block:: markdown

        * [ ] تحديث الأخبار وتاريخ "ما الجديد" في فرع الإصدار
        * [ ] التراجع عن الأخبار وتاريخ "ما الجديد" في فرع الإصدار
        * [ ] تعيين رقم الإصدار في فرع الإصدار
        * [ ] تأكد من أنه يمكن بناء العجلات للإصدار بنجاح
        * [ ] دمج PR مع علامة الالتزام `[cd build]` لتحميل العجلات إلى المستودع المرحلي
        * [ ] تحميل العجلات وحزمة المصدر إلى https://test.pypi.org
        * [ ] تحميل العجلات وحزمة المصدر إلى https://pypi.org
        * [ ] تأكيد على قائمة البريد الإلكتروني وعلى تويتر، وعلى LinkedIn
        * [ ] تحديث symlink لـ "stable" في https://github.com/scikit-learn/scikit-learn.github.io
        * [ ] تحديث SECURITY.md في فرع main

    
    - إعادة قاعدة هذا PR من فرع `1.6`.X:

      .. prompt:: bash

        git rebase -i upstream/1.6.X

      سيؤدي هذا إلى فتح إعادة قاعدة تفاعلية مع `git-rebase-todo` تحتوي على جميع
      أحدث الالتزامات على `main`. في هذه المرحلة، يجب عليك إجراء هذه إعادة القاعدة التفاعلية
      مع شخص آخر على الأقل (لتجنب نسيان شيء وتجنب الشكوك).

      - لا تقم بإزالة الأسطر ولكن قم بإسقاط الالتزام عن طريق استبدال `pick` بـ `drop`.
      - الالتزامات لالتقاط لإصدار إصلاح الأخطاء عمومًا البادئة `FIX`، `CI`،
        و `DOC`. يجب أن تتضمن على الأقل جميع الالتزامات من PRs التي تم وضع علامة عليها للميل
        و/أو الموثقة على هذا النحو في سجل التغييرات.
      - الالتزامات لـ `drop` لإصدار إصلاح الأخطاء عمومًا لها البادئة `FEAT`،
        `MAINT`، `ENH`، و `API`. أسباب عدم تضمينها هي منع التغيير
        السلوك (الذي يجب أن يحدث فقط في الإصدارات الرئيسية/الثانوية).
    - لا تخرج ولكن الصق محتوى ملف `git-rebase-todo` في PR. يوجد هذا الملف في
        `.git/rebase-merge/git-rebase-todo`.
    - احفظ وأخرج لبدء إعادة القاعدة التفاعلية. حل تعارضات الدمج عند
        الضرورة.
    

    

    - في فرع `1.6`.X`، قم بتغيير رقم الإصدار `__version__` في
      `sklearn/__init__.py` إلى `1.6.0`.

    
    - في فرع `main`، قم بتحرير الملف المقابل في دليل `doc/whats_new`
      لتحديث تاريخ الإصدار, ربط مثال أبرز الإصدارات،
      وإضافة قائمة بأسماء المساهمين. لنفترض أن علامة الإصدار الأخير في
      الإصدار السابق في الإصدار الرئيسي/الثانوي السابق هو `1.5.2`، ثم يمكنك استخدام
      الأمر التالي لاسترداد قائمة بأسماء المساهمين:

      .. prompt:: bash

        git shortlog -s 1.5.2.. |
          cut -f2- |
          sort --ignore-case |
          tr "\n" ";" |
          sed "s/;/, /g;s/, $//" |
          fold -s

      ثم قم باختيارها في فرع الإصدار `1.6.X`.

    - في فرع `main`، قم بتحرير `doc/templates/index.html` لتغيير قسم "الأخبار"
      في صفحة الهبوط، إلى جانب شهر الإصدار.
      لا تنسَ إزالة الإدخالات القديمة (سنتان أو ثلاث إصدارات مضت) وتحديث
      إدخال "التطوير الجاري".
      ثم قم باختياره في فرع الإصدار `1.6.X`.
    

    - قم بتشغيل أداة بناء العجلة مع علامة الالتزام `[cd build]`. راجع أيضًا
      `تشغيل سير عمل أداة بناء العجلة
      <https://github.com/scikit-learn/scikit-learn/actions/workflows/wheels.yml>`_.

      .. prompt:: bash

        git commit --allow-empty -m "[cd build] Trigger wheel builder workflow"

      .. note::

        يرمز الاختصار CD في `[cd build]` إلى `Continuous Delivery
        <https://en.wikipedia.org/wiki/Continuous_delivery>`_ ويشير إلى
        الأتمتة المستخدمة لتوليد عناصر الإصدار (الحزم الثنائية والمصدر)
        . يمكن اعتبار هذا امتدادًا لـ CI الذي يرمز إلى `Continuous
        Integration <https://en.wikipedia.org/wiki/Continuous_integration>`_. يستخدم سير عمل CD على GitHub Actions أيضًا لإنشاء إصدارات ليلية ونشر الحزم
        لفرع التطوير من scikit-learn. راجع أيضًا :ref:`install_nightly_builds`.

    - بمجرد اكتمال جميع وظائف CD بنجاح في PR، قم بدمجها مع
      علامة `[cd build]` في رسالة الالتزام. هذه المرة سيتم
      تحميل النتائج إلى منطقة المرحلية. بعد ذلك، يجب أن تتمكن من تحميل العناصر المولدة
      (ملفات `.tar.gz` و `.whl`) إلى https://test.pypi.org/ باستخدام نموذج "تشغيل سير العمل"
      لسير عمل النشر على PyPI
      <https://github.com/scikit-learn/scikit-learn/actions/workflows/publish_pypi.yml>`_.

      .. warning::

        يجب دمج هذا PR باستخدام وضع إعادة القاعدة بدلاً من وضع السحق المعتاد
        لأننا نريد الحفاظ على التاريخ في فرع `1.6.X` قريبًا
        تاريخ فرع `main` والذي سيساعد في الإصدارات المستقبلية لإصلاح الأخطاء.

        بالإضافة إلى أنه إذا كان الالتزام الأخير، الذي يحتوي على علامة `[cd build]`، فارغًا،
        لن يتم تشغيل وظائف CD. في هذه الحالة، يمكنك دفع التزام مباشرةً بعلامة في `1.6.X`
        لتشغيلها.

    - إذا سارت الخطوات أعلاه على ما يرام، فانتقل **بحرص** لإنشاء علامة جديدة للإصدار. يجب القيام بذلك فقط عندما تكون
      متأكدًا تقريبًا من أن الإصدار جاهز، حيث يمكن أن يؤدي إضافة علامة جديدة إلى المستودع الرئيسي إلى تشغيل
      بعض العمليات الآلية.

      .. prompt:: bash

        git tag -a 1.6.0  # في فرع 1.6.X
        git push git@github.com:scikit-learn/scikit-learn.git 1.6.0

    - تأكد من أن البوت قد اكتشف العلامة على مستودع conda-forge feedstock
      https://github.com/conda-forge/scikit-learn-feedstock. إذا لم يكن الأمر كذلك، فتقدم بطلب سحب للإصدار،
      استهداف الفرع `main`.

    - قم بتشغيل سير عمل النشر على PyPI
      <https://github.com/scikit-learn/scikit-learn/actions/workflows/publish_pypi.yml>`__
      مرة أخرى، ولكن هذه المرة لتحميل العناصر إلى https://pypi.org/ الحقيقي. للقيام بذلك،
      استبدل `testpypi` بـ `pypi` في نموذج "تشغيل سير العمل".

      **بدلاً من ذلك**، من الممكن جمع عجلات الحزم الثنائية المحلية وحزم المصدر وتحميلها جميعًا إلى PyPI.

      .. dropdown:: تحميل العناصر من محلي

        قم بالتحقق من علامة الإصدار وقم بتشغيل الأوامر التالية.

        .. prompt:: bash

          rm -r dist
          python -m pip install -U wheelhouse_uploader twine
          python -m wheelhouse_uploader fetch \
            --version 0.99.0rc1 --local-folder dist scikit-learn \
            https://pypi.anaconda.org/scikit-learn-wheels-staging/simple/scikit-learn/

        ستقوم هذه الأوامر بتنزيل جميع الحزم الثنائية التي تم تجميعها في `منطقة المرحلية
        على خدمة استضافة anaconda.org
        <https://anaconda.org/scikit-learn-wheels-staging/scikit-learn/files>`_ ووضعها في
        المجلد المحلي الخاص بك `./dist`. تحقق من محتويات المجلد `./dist`:
        يجب أن يحتوي على جميع العجلات إلى جانب حزمة المصدر `.tar.gz`. تأكد من عدم وجود إصدارات مطورة أو إصدارات قديمة من حزمة scikit-learn
        في هذا المجلد. قبل التحميل إلى PyPI، يمكنك اختبار التحميل إلى
        `test.pypi.org` أولاً.

        .. prompt:: bash

          twine upload --verbose --repository-url https://test.pypi.org/legacy/ dist/*

        ثم قم بتحميل كل شيء مرة واحدة إلى `pypi.org`.

        .. prompt:: bash

          twine upload dist/*

    
    - تحديث symlink لـ "stable" ومتغير `latestStable` في
      `versionwarning.js` في https://github.com/scikit-learn/scikit-learn.github.io.

      .. prompt:: bash

        cd /tmp
        git clone --depth 1 --no-checkout git@github.com:scikit-learn/scikit-learn.github.io.git
        cd scikit-learn.github.io
        echo stable > .git/info/sparse-checkout
        git checkout main
        rm stable
        ln -s 1.6 stable
        sed -i "s/latestStable = '.*/latestStable = '1.6';/" versionwarning.js
        git add stable versionwarning.js
        git commit -m "Update stable to point to 1.6"
        git push origin main
    

    
    - تحديث `SECURITY.md` لتعكس أحدث إصدار مدعوم `1.6.0`.
    
  .. tab-item:: Bug-fix
    :class-label: tab-4

    لنفترض أننا نقوم بإعداد الإصدار `1.5.3`.

    

    - قم بإنشاء PR من الفرع `main` الذي يستهدف فرع `1.5.X`.
      قم بنسخ قائمة التحقق من الإصدار هذه إلى وصف هذا PR لتتبع
      التقدم.

      .. code-block:: markdown

        * [ ] تحديث الأخبار وتاريخ "ما الجديد" في فرع الإصدار
        * [ ] التراجع عن الأخبار وتاريخ "ما الجديد" في فرع الإصدار
        * [ ] تعيين رقم الإصدار في فرع الإصدار
        * [ ] تأكد من أنه يمكن بناء العجلات للإصدار بنجاح
        * [ ] دمج PR مع علامة الالتزام `[cd build]` لتحميل العجلات إلى المستودع المرحلي
        * [ ] تحميل العجلات وحزمة المصدر إلى https://test.pypi.org
        * [ ] تحميل العجلات وحزمة المصدر إلى https://pypi.org
        * [ ] تأكيد على قائمة البريد الإلكتروني وعلى تويتر، وعلى LinkedIn
        * [ ] تحديث SECURITY.md في فرع main

    
    - إعادة قاعدة هذا PR من فرع `1.5`.X:

      .. prompt:: bash

        git rebase -i upstream/1.5.X

      سيؤدي هذا إلى فتح إعادة قاعدة تفاعلية مع `git-rebase-todo` تحتوي على جميع
      أحدث الالتزامات على `main`. في هذه المرحلة، يجب عليك إجراء هذه إعادة القاعدة التفاعلية
      مع شخص آخر على الأقل (لتجنب نسيان شيء وتجنب الشكوك).

      - لا تقم بإزالة الأسطر ولكن قم بإسقاط الالتزام عن طريق استبدال `pick` بـ `drop`.
      - الالتزامات لالتقاط لإصدار إصلاح الأخطاء عمومًا البادئة `FIX`، `CI`،
        و `DOC`. يجب أن تتضمن على الأقل جميع الالتزامات من PRs التي تم وضع علامة عليها للميل
        و/أو الموثقة على هذا النحو في سجل التغييرات.
      - الالتزامات لـ `drop` لإصدار إصلاح الأخطاء عمومًا لها البادئة `FEAT`،
        `MAINT`، `ENH`، و `API`. أسباب عدم تضمينها هي منع التغيير
        السلوك (الذي يجب أن يحدث فقط في الإصدارات الرئيسية/الثانوية).
    - لا تخرج ولكن الصق محتوى ملف `git-rebase-todo` في PR. يوجد هذا الملف في
        `.git/rebase-merge/git-rebase-todo`.
    - احفظ وأخرج لبدء إعادة القاعدة التفاعلية. حل تعارضات الدمج عند
        الضرورة.
    

    

    - في فرع `1.5`.X`، قم بتغيير رقم الإصدار `__version__` في
      `sklearn/__init__.py` إلى `1.5.3`.

    
    - في فرع `main`، قم بتحرير الملف المقابل في دليل `doc/whats_new`
      لتحديث تاريخ الإصدار
      وإضافة قائمة بأسماء المساهمين. لنفترض أن علامة الإصدار الأخير في
      الإصدار السابق في الإصدار الرئيسي/الثانوي السابق هو `1.4.2`، ثم يمكنك استخدام
      الأمر التالي لاسترداد قائمة بأسماء المساهمين:

      .. prompt:: bash

        git shortlog -s 1.4.2.. |
          cut -f2- |
          sort --ignore-case |
          tr "\n" ";" |
          sed "s/;/, /g;s/, $//" |
          fold -s

      ثم قم باختيارها في فرع الإصدار `1.5.X`.

    - في فرع `main`، قم بتحرير `doc/templates/index.html` لتغيير قسم "الأخبار"
      في صفحة الهبوط، إلى جانب شهر الإصدار.
      ثم قم باختياره في فرع الإصدار `1.5.X`.
    

    - قم بتشغيل أداة بناء العجلة مع علامة الالتزام `[cd build]`. راجع أيضًا
      `تشغيل سير عمل أداة بناء العجلة
      <https://github.com/scikit-learn/scikit-learn/actions/workflows/wheels.yml>`_.

      .. prompt:: bash

        git commit --allow-empty -m "[cd build] Trigger wheel builder workflow"

      .. note::

        يرمز الاختصار CD في `[cd build]` إلى `Continuous Delivery
        <https://en.wikipedia.org/wiki/Continuous_delivery>`_ ويشير إلى
        الأتمتة المستخدمة لتوليد عناصر الإصدار (الحزم الثنائية والمصدر)
        . يمكن اعتبار هذا امتدادًا لـ CI الذي يرمز إلى `Continuous
        Integration <https://en.wikipedia.org/wiki/Continuous_integration>`_. يستخدم سير عمل CD على GitHub Actions أيضًا لإنشاء إصدارات ليلية ونشر الحزم
        لفرع التطوير من scikit-learn. راجع أيضًا :ref:`install_nightly_builds`.

    - بمجرد اكتمال جميع وظائف CD بنجاح في PR، قم بدمجها مع
      علامة `[cd build]` في رسالة الالتزام. هذه المرة سيتم
      تحميل النتائج إلى منطقة المرحلية. بعد ذلك، يجب أن تتمكن من تحميل العناصر المولدة
      (ملفات `.tar.gz` و `.whl`) إلى https://test.pypi.org/ باستخدام نموذج "تشغيل سير العمل"
      لسير عمل النشر على PyPI
      <https://github.com/scikit-learn/scikit-learn/actions/workflows/publish_pypi.yml>`_.

      .. warning::

        يجب دمج هذا PR باستخدام وضع إعادة القاعدة بدلاً من وضع السحق المعتاد
        لأننا نريد الحفاظ على التاريخ في فرع `1.5.X` قريبًا
        تاريخ فرع `main` والذي سيساعد في الإصدارات المستقبلية لإصلاح الأخطاء.

        بالإضافة إلى أنه إذا كان الالتزام الأخير، الذي يحتوي على علامة `[cd build]`، فارغًا،
        لن يتم تشغيل وظائف CD. في هذه الحالة، يمكنك دفع التزام مباشرةً بعلامة في `1.5.X`
        لتشغيلها.

    - إذا سارت الخطوات أعلاه على ما يرام، فانتقل **بحرص** لإنشاء علامة جديدة للإصدار. يجب القيام بذلك فقط عندما تكون
      متأكدًا تقريبًا من أن الإصدار جاهز، حيث يمكن أن يؤدي إضافة علامة جديدة إلى المستودع الرئيسي إلى تشغيل
      بعض العمليات الآلية.

      .. prompt:: bash

        git tag -a 1.5.3  # في فرع 1.5.X
        git push git@github.com:scikit-learn/scikit-learn.git 1.5.3

    - تأكد من أن البوت قد اكتشف العلامة على مستودع conda-forge feedstock
      https://github.com/conda-forge/scikit-learn-feedstock. إذا لم يكن الأمر كذلك، فتقدم بطلب سحب للإصدار،
      استهداف الفرع `main`.

    - قم بتشغيل سير عمل النشر على PyPI
      <https://github.com/scikit-learn/scikit-learn/actions/workflows/publish_pypi.yml>`__
      مرة أخرى، ولكن هذه المرة لتحميل العناصر إلى https://pypi.org/ الحقيقي. للقيام بذلك،
      استبدل `testpypi` بـ `pypi` في نموذج "تشغيل سير العمل".

      **بدلاً من ذلك**، من الممكن جمع عجلات الحزم الثنائية المحلية وحزم المصدر وتحميلها جميعًا إلى PyPI.

      .. dropdown:: تحميل العناصر من محلي

        قم بالتحقق من علامة الإصدار وقم بتشغيل الأوامر التالية.

        .. prompt:: bash

          rm -r dist
          python -m pip install -U wheelhouse_uploader twine
          python -m wheelhouse_uploader fetch \
            --version 0.99.0rc1 --local-folder dist scikit-learn \
            https://pypi.anaconda.org/scikit-learn-wheels-staging/simple/scikit-learn/

        ستقوم هذه الأوامر بتنزيل جميع الحزم الثنائية التي تم تجميعها في `منطقة المرحلية
        على خدمة استضافة anaconda.org
        <https://anaconda.org/scikit-learn-wheels-staging/scikit-learn/files>`_ ووضعها في
        المجلد المحلي الخاص بك `./dist`. تحقق من محتويات المجلد `./dist`:
        يجب أن يحتوي على جميع العجلات إلى جانب حزمة المصدر `.tar.gz`. تأكد من عدم وجود إصدارات مطورة أو إصدارات قديمة من حزمة scikit-learn
        في هذا المجلد. قبل التحميل إلى PyPI، يمكنك اختبار التحميل إلى
        `test.pypi.org` أولاً.

        .. prompt:: bash

          twine upload --verbose --repository-url https://test.pypi.org/legacy/ dist/*

        ثم قم بتحميل كل شيء مرة واحدة إلى `pypi.org`.

        .. prompt:: bash

          twine upload dist/*

    

    
    - تحديث `SECURITY.md` لتعكس أحدث إصدار مدعوم `1.5.3`.
    
  

تحديث قائمة المؤلفين
---------------------

يتعلق هذا القسم بتحديث :ref:`authors`. قم بإنشاء `رمز كلاسيكي على GitHub
<https://github.com/settings/tokens/new>`_ مع إذن `read:org`. ثم قم بتشغيل
النص البرمجي التالي وأدخل الرمز عند المطالبة:

.. prompt:: bash

  cd build_tools
  make authors  # أدخل الرمز عند المطالبة

دمج طلبات السحب
------------------

يتم سحق الالتزامات الفردية عند دمج PR على GitHub. قبل الدمج:

- يمكن تحرير عنوان الالتزام الناتج إذا لزم الأمر. لاحظ أن هذا سيؤدي إلى إعادة تسمية
  عنوان PR افتراضيًا.
- يمكن تحرير الوصف التفصيلي، الذي يحتوي على عناوين جميع الالتزامات، أو حذفه.
- بالنسبة إلى PRs مع عدة مساهمين في الكود، يجب توخي الحذر للحفاظ على
  `Co-authored-by: name <name@example.com>` العلامات في الوصف التفصيلي. سيؤدي هذا إلى
  وضع علامة على PR على أنه يحتوي على `عدة مؤلفين متعاونين
  <https://help.github.com/en/github/committing-changes-to-your-project/creating-a-commit-with-multiple-authors>`_.
  سواء كانت المساهمات البرمجية مهمة بما يكفي لتبرير التأليف المشترك متروك لتقدير المسؤول، كما هو الحال بالنسبة لإدخال "ما الجديد".

موقع scikit-learn.org
-----------------------

يتم استضافة موقع scikit-learn (https://scikit-learn.org) على GitHub، ولكن يجب
نادرًا ما يتم تحديثه يدويًا عن طريق الدفع إلى
مستودع https://github.com/scikit-learn/scikit-learn.github.io. يمكن إجراء معظم التحديثات عن طريق الدفع إلى `main` (لـ `/dev`) أو فرع الإصدار `A.B.X`، والذي يقوم Circle CI
ببنائه وتحميل الوثائق تلقائيًا.

الميزات التجريبية
---------------------

تم تقديم الوحدة النمطية :mod:`sklearn.experimental` في 0.21 وتحتوي
على ميزات ومقدرات تجريبية تخضع للتغيير دون
دورة التقادم.

لإنشاء وحدة نمطية تجريبية، راجع محتويات `enable_halving_search_cv.py
<https://github.com/scikit-learn/scikit-learn/blob/362cb92bb2f5b878229ea4f59519ad31c2fcee76/sklearn/experimental/enable_halving_search_cv.py>`__،
أو `enable_iterative_imputer.py
<https://github.com/scikit-learn/scikit-learn/blob/c9c89cfc85dd8dfefd7921c16c87327d03140a06/sklearn/experimental/enable_iterative_imputer.py>`__.

.. note::

  هذه هي الروابط الدائمة كما في 0.24، حيث لا تزال هذه المقدرات تجريبية. قد تكون مستقرة في وقت القراءة، وبالتالي الرابط الدائم. راجع أدناه للحصول على التعليمات الخاصة بالانتقال من تجريبي إلى مستقر.

لاحظ أنه يجب أن يكون مسار الاستيراد العام إلى حزمة فرعية عامة (مثل `sklearn/ensemble`
أو `sklearn/impute`)، وليس فقط ملف `.py`. أيضًا، يجب استيراد الميزات التجريبية الخاصة (الخاصة)
في حزمة فرعية/حزمة فرعية للحزمة الفرعية العامة، على سبيل المثال
`sklearn/ensemble/_hist_gradient_boosting/` أو `sklearn/impute/_iterative.py`. هذا
مطلوب حتى تعمل عمليات التخليل في المستقبل عندما لا تكون الميزات تجريبية
بعد الآن.

لتجنب أخطاء مدقق النوع (مثل `mypy`)، يجب إجراء استيراد مباشر للمقدرات التجريبية
في الوحدة النمطية الأصلية، محميًا بواسطة التحقق من `if typing.TYPE_CHECKING`.
راجع `sklearn/ensemble/__init__.py
<https://github.com/scikit-learn/scikit-learn/blob/c9c89cfc85dd8dfefd7921c16c87327d03140a06/sklearn/ensemble/__init__.py>`__،
أو `sklearn/impute/__init__.py
<https://github.com/scikit-learn/scikit-learn/blob/c9c89cfc85dd8dfefd7921c16c87327d03140a06/sklearn/impute/__init__.py>`__
لمثال. يرجى أيضًا كتابة اختبارات أساسية وفقًا لتلك الموجودة في
`test_enable_hist_gradient_boosting.py
<https://github.com/scikit-learn/scikit-learn/blob/c9c89cfc85dd8dfefd7921c16c87327d03140a06/sklearn/experimental/tests/test_enable_hist_gradient_boosting.py>`__.

تأكد من أن كل كود يواجه المستخدم الذي تكتبه يذكر صراحةً أن الميزة تجريبية، وأضف تعليق `# noqa` لتجنب التحذيرات المتعلقة بـ PEP8::

  # لاستخدام هذه الميزة التجريبية، نحتاج إلى طلبها صراحةً
  from sklearn.experimental import enable_iterative_imputer  # noqa
  from sklearn.impute import IterativeImputer

لجعل الوثائق تظهر بشكل صحيح، يرجى أيضًا استيراد `enable_my_experimental_feature` في
`doc/conf.py`، وإلا لن تتمكن sphinx من اكتشاف واستيراد الوحدات النمطية المقابلة. لاحظ أن استخدام `from sklearn.experimental import *` **لا يعمل**.

.. note::

  قد لا يتم تضمين بعض الفئات والوظائف التجريبية في الوحدة النمطية
  :mod:`sklearn.experimental`، على سبيل المثال، `sklearn.datasets.fetch_openml`.

بمجرد أن تصبح الميزة مستقرة، قم بإزالة جميع حالات حدوث `enable_my_experimental_feature` في قاعدة كود scikit-learn وجعل
`enable_my_experimental_feature` لا تعمل إلا عن طريق رفع تحذير، كما هو الحال في
`enable_hist_gradient_boosting.py
<https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/experimental/enable_hist_gradient_boosting.py>`__.
يجب أن يظل الملف هناك إلى أجل غير مسمى حيث لا نريد كسر كود المستخدمين؛ نحن فقط
نحفزهم على إزالة هذا الاستيراد بالتحذير. تذكر أيضًا تحديث
الاختبارات وفقًا لذلك، راجع `test_enable_hist_gradient_boosting.py
<https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/experimental/tests/test_enable_hist_gradient_boosting.py>`__.