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

الإصدار

يتعلق هذا القسم بإعداد إصدار رئيسي/ثانوي، أو إصدار مرشح (RC)، أو إصدار إصلاح الأخطاء. نتبع PEP440 لمخطط الإصدار وللإشارة إلى أنواع مختلفة من الإصدارات. اتفاقيتنا هي اتباع مخطط "major.minor.micro"، على الرغم من أنه في الممارسة العملية لا يوجد فرق أساسي بين الإصدارات الرئيسية والثانوية والإصدارات الصغيرة هي إصدارات إصلاح الأخطاء.

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

• الإصدارات الرئيسية/الثانوية كل 6 أشهر، عادة في شهري مايو ونوفمبر. يتم ترقيم هذه الإصدارات X.Y.0 ويسبقها إصدار مرشح واحد أو أكثر X.Y.0rcN.

• يتم إجراء إصدارات إصلاح الأخطاء حسب الحاجة بين الإصدارات الرئيسية/الثانوية وتنطبق فقط على أحدث إصدار مستقر. يتم ترقيم هذه الإصدارات X.Y.Z.

التحضير

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

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

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

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

الأذونات

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

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

خطوات مرجعية

Major/Minor RC

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

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

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

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

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

  * [ ] تحديث الأخبار وتاريخ "ما الجديد" في فرع الإصدار
  * [ ] التراجع عن الأخبار وتاريخ "ما الجديد" في فرع الإصدار
  * [ ] تحديث إصدار 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]. راجع أيضًا تشغيل سير عمل أداة بناء العجلة.

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

  ملاحظة

  يرمز الاختصار CD في [cd build] إلى Continuous Delivery ويشير إلى الأتمتة المستخدمة لتوليد عناصر الإصدار (الحزم الثنائية والمصدر) . يمكن اعتبار هذا امتدادًا لـ CI الذي يرمز إلى Continuous Integration. يستخدم سير عمل CD على GitHub Actions أيضًا لإنشاء إصدارات ليلية ونشر الحزم لفرع التطوير من scikit-learn. راجع أيضًا تثبيت النسخ الليلية.

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

  تحذير

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

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

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

  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 conda-forge/scikit-learn-feedstock. إذا لم يكن الأمر كذلك، فتقدم بطلب سحب للإصدار، استهداف الفرع rc.

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

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

  تحميل العناصر من محلي

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

  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 ووضعها في المجلد المحلي الخاص بك ./dist. تحقق من محتويات المجلد ./dist: يجب أن يحتوي على جميع العجلات إلى جانب حزمة المصدر .tar.gz. تأكد من عدم وجود إصدارات مطورة أو إصدارات قديمة من حزمة scikit-learn في هذا المجلد. قبل التحميل إلى PyPI، يمكنك اختبار التحميل إلى test.pypi.org أولاً.

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

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

  twine upload dist/*
  

Major/Minor Final

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

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

  * [ ] تحديث الأخبار وتاريخ "ما الجديد" في فرع الإصدار
  * [ ] التراجع عن الأخبار وتاريخ "ما الجديد" في فرع الإصدار
  * [ ] تعيين رقم الإصدار في فرع الإصدار
  * [ ] تأكد من أنه يمكن بناء العجلات للإصدار بنجاح
  * [ ] دمج 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:

  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، ثم يمكنك استخدام الأمر التالي لاسترداد قائمة بأسماء المساهمين:

  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]. راجع أيضًا تشغيل سير عمل أداة بناء العجلة.

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

  ملاحظة

  يرمز الاختصار CD في [cd build] إلى Continuous Delivery ويشير إلى الأتمتة المستخدمة لتوليد عناصر الإصدار (الحزم الثنائية والمصدر) . يمكن اعتبار هذا امتدادًا لـ CI الذي يرمز إلى Continuous Integration. يستخدم سير عمل CD على GitHub Actions أيضًا لإنشاء إصدارات ليلية ونشر الحزم لفرع التطوير من scikit-learn. راجع أيضًا تثبيت النسخ الليلية.

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

  تحذير

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

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

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

  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 conda-forge/scikit-learn-feedstock. إذا لم يكن الأمر كذلك، فتقدم بطلب سحب للإصدار، استهداف الفرع main.

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

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

  تحميل العناصر من محلي

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

  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 ووضعها في المجلد المحلي الخاص بك ./dist. تحقق من محتويات المجلد ./dist: يجب أن يحتوي على جميع العجلات إلى جانب حزمة المصدر .tar.gz. تأكد من عدم وجود إصدارات مطورة أو إصدارات قديمة من حزمة scikit-learn في هذا المجلد. قبل التحميل إلى PyPI، يمكنك اختبار التحميل إلى test.pypi.org أولاً.

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

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

  twine upload dist/*
  

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

  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.

Bug-fix

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

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

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

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

  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، ثم يمكنك استخدام الأمر التالي لاسترداد قائمة بأسماء المساهمين:

  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]. راجع أيضًا تشغيل سير عمل أداة بناء العجلة.

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

  ملاحظة

  يرمز الاختصار CD في [cd build] إلى Continuous Delivery ويشير إلى الأتمتة المستخدمة لتوليد عناصر الإصدار (الحزم الثنائية والمصدر) . يمكن اعتبار هذا امتدادًا لـ CI الذي يرمز إلى Continuous Integration. يستخدم سير عمل CD على GitHub Actions أيضًا لإنشاء إصدارات ليلية ونشر الحزم لفرع التطوير من scikit-learn. راجع أيضًا تثبيت النسخ الليلية.

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

  تحذير

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

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

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

  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 conda-forge/scikit-learn-feedstock. إذا لم يكن الأمر كذلك، فتقدم بطلب سحب للإصدار، استهداف الفرع main.

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

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

  تحميل العناصر من محلي

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

  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 ووضعها في المجلد المحلي الخاص بك ./dist. تحقق من محتويات المجلد ./dist: يجب أن يحتوي على جميع العجلات إلى جانب حزمة المصدر .tar.gz. تأكد من عدم وجود إصدارات مطورة أو إصدارات قديمة من حزمة scikit-learn في هذا المجلد. قبل التحميل إلى PyPI، يمكنك اختبار التحميل إلى test.pypi.org أولاً.

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

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

  twine upload dist/*
  

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

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

يتعلق هذا القسم بتحديث الأشخاص وراء Scikit-learn. قم بإنشاء رمز كلاسيكي على GitHub مع إذن read:org. ثم قم بتشغيل النص البرمجي التالي وأدخل الرمز عند المطالبة:

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

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

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

• يمكن تحرير عنوان الالتزام الناتج إذا لزم الأمر. لاحظ أن هذا سيؤدي إلى إعادة تسمية عنوان PR افتراضيًا.

• يمكن تحرير الوصف التفصيلي، الذي يحتوي على عناوين جميع الالتزامات، أو حذفه.

• بالنسبة إلى PRs مع عدة مساهمين في الكود، يجب توخي الحذر للحفاظ على Co-authored-by: name <name@example.com> العلامات في الوصف التفصيلي. سيؤدي هذا إلى وضع علامة على PR على أنه يحتوي على عدة مؤلفين متعاونين. سواء كانت المساهمات البرمجية مهمة بما يكفي لتبرير التأليف المشترك متروك لتقدير المسؤول، كما هو الحال بالنسبة لإدخال "ما الجديد".

موقع scikit-learn.org

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

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

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

لإنشاء وحدة نمطية تجريبية، راجع محتويات enable_halving_search_cv.py، أو enable_iterative_imputer.py.

ملاحظة

هذه هي الروابط الدائمة كما في 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، أو sklearn/impute/__init__.py لمثال. يرجى أيضًا كتابة اختبارات أساسية وفقًا لتلك الموجودة في 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 * لا يعمل.

ملاحظة

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

بمجرد أن تصبح الميزة مستقرة، قم بإزالة جميع حالات حدوث enable_my_experimental_feature في قاعدة كود scikit-learn وجعل enable_my_experimental_feature لا تعمل إلا عن طريق رفع تحذير، كما هو الحال في enable_hist_gradient_boosting.py. يجب أن يظل الملف هناك إلى أجل غير مسمى حيث لا نريد كسر كود المستخدمين؛ نحن فقط نحفزهم على إزالة هذا الاستيراد بالتحذير. تذكر أيضًا تحديث الاختبارات وفقًا لذلك، راجع test_enable_hist_gradient_boosting.py.