معلومات المسؤول#
الإصدار#
يتعلق هذا القسم بإعداد إصدار رئيسي/ثانوي، أو إصدار مرشح (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
في طلب السحب الأول للإصدار.
خطوات مرجعية#
لنفترض أننا نقوم بإعداد الإصدار 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/*
لنفترض أننا نقوم بإعداد الإصدار 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
.
لنفترض أننا نقوم بإعداد الإصدار 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.