From ec58d1799df6dc7a1c114f602cdfcd22e64953cf Mon Sep 17 00:00:00 2001 From: Olivier Grisel Date: Wed, 2 Dec 2020 10:31:52 +0100 Subject: [PATCH 01/14] DOC more updates to maintainers' doc --- doc/developers/maintainer.rst | 79 ++++++++++++++++++++++------------- 1 file changed, 51 insertions(+), 28 deletions(-) diff --git a/doc/developers/maintainer.rst b/doc/developers/maintainer.rst index 97d5a7dfe2f05..3daf78f6f1d9b 100644 --- a/doc/developers/maintainer.rst +++ b/doc/developers/maintainer.rst @@ -66,26 +66,31 @@ under that branch. In terms of including changes, the first RC ideally counts as a *feature freeze*. Each coming release candidate and the final release afterwards will -include minor documentation changes and bug fixes. Any major enhancement or -feature should be excluded. +include only minor documentation changes and bug fixes. Any major enhancement +or feature should be excluded. The minor releases should include bug fixes and some relevant documentation changes only. Any PR resulting in a behavior change which is not a bug fix should be excluded. -First, create a branch, **on your own fork** (to release e.g. `0.999.3`): +For major releases, do not forget to prepare a Release Highlights page as a +runnable example and check that its HTML rendering looks correct. These release +higlights should be linked from the ``whats_new.html`` file for the new version +of scikit-learn. + +First, create a branch, **on your own fork** (to release e.g. `0.99.3`): .. prompt:: bash $ # assuming master and upstream/master are the same - git checkout -b release-0.999.3 master + git checkout -b release-0.99.3 master -Then, create a PR **to the** `scikit-learn/0.999.X` **branch** (not to +Then, create a PR **to the** `scikit-learn/0.99.X` **branch** (not to master!) with all the desired changes: .. prompt:: bash $ - git rebase -i upstream/0.999.2 + git rebase -i upstream/0.99.2 Do not forget to add a commit updating sklearn.__version__. @@ -109,17 +114,21 @@ Making a release the RC releases. These changes should be made in master and cherry-picked into the release branch, only before the final release. - - Edit the doc/whats_new.rst file to add release title and commit - statistics. You can retrieve commit statistics with: + - Edit the ``doc/v0.99/whats_new.rst`` file to add release title and list of + contributors. + You can retrieve the list of contributor names with: :: - $ git shortlog -s 0.99.33.. | cut -f2- | sort --ignore-case | tr '\n' ';' | sed 's/;/, /g;s/, $//' + $ git shortlog -s 0.98.33.. | cut -f2- | sort --ignore-case | tr '\n' ';' | sed 's/;/, /g;s/, $//' + + For major releases, make sure that the release highlights example is + properly linked from the ``doc/v0.99/whats_new.rst`` file. - Update the release date in ``whats_new.rst`` - - Edit the doc/templates/index.html to change the 'News' entry of the front - page. + - Edit the ``doc/templates/index.html`` to change the 'News' entry of the + front page (with the release month as well). 2. On the branch for releasing, update the version number in `sklearn/__init__.py`, the ``__version__`` variable by removing ``dev*`` @@ -141,7 +150,21 @@ Making a release The wheel building workflow is managed by GitHub Actions and the results be browsed at: https://github.com/scikit-learn/scikit-learn/actions?query=workflow%3A%22Wheel+builder%22 - Once all works, you can proceed with tagging. Create the tag and push it (if +.. note:: + + Before building the wheels, make sure that the ``pyproject.toml`` file is + up to date and using the oldest version of ``numpy`` for each Python version + to avoid ABI incompatibility issues. Moreover, a new line have to be included + in the ``pyproject.toml`` file for each new supported version of Python. + +4. Once the CD has completed successfully, upload the generated artifacts + (.tar.gz and .whl files) to https://test.pypi.org using the "Run workflow" + form for the following GitHub Actions workflow: + + https://github.com/scikit-learn/scikit-learn/actions?query=workflow%3A%22Publish+to+Pypi%22 + + +5. If this went fine, you can proceed with tagging. Create the tag and push it (if it's an RC, it can be ``0.xxrc1`` for instance): .. prompt:: bash $ @@ -149,16 +172,14 @@ Making a release git tag -a 0.99 # in the 0.99.X branch git push git@github.com:scikit-learn/scikit-learn.git 0.99 -.. note:: - - Before building the wheels, make sure that the ``pyproject.toml`` file is - up to date and using the oldest version of ``numpy`` for each Python version - to avoid ABI incompatibility issues. Moreover, a new line have to be included - in the ``pyproject.toml`` file for each new supported version of Python. +6. Trigger the GitHub Actions workflow again but this time to upload the artifacts + to the real https://pypi.org (replace "testpypi" by "pypi" in the "Run + workflow" form). -4. Once the CD has completed successfully, collect the generated binary - wheel packages and upload them to PyPI by running the following commands - in the scikit-learn source folder (checked out at the release tag): +7. Alternatively, it's possible to collect locally the generated binary wheel + packages and source tarbakk and upload them all to PyPI by running the + following commands in the scikit-learn source folder (checked out at the + release tag): .. prompt:: bash $ @@ -166,11 +187,12 @@ Making a release pip install -U wheelhouse_uploader twine python setup.py fetch_artifacts - This command will download all the binary packages accumulated in the `staging area on the anaconda.org - hosting service `_ and put them in - your local `./dist` folder. + This command will download all the binary packages accumulated in the + `staging area on the anaconda.org hosting service + `_ and + put them in your local `./dist` folder. -5. Check the content of the `./dist` folder: it should contain all the wheels + Check the content of the `./dist` folder: it should contain all the wheels along with the source tarball ("scikit-learn-RRR.tar.gz"). Make sure that you do not have developer versions or older versions of @@ -188,7 +210,7 @@ Making a release twine upload dist/* -6. For major/minor (not bug-fix release), update the symlink for ``stable`` +8. For major/minor (not bug-fix release), update the symlink for ``stable`` and the ``latestStable`` variable in https://github.com/scikit-learn/scikit-learn.github.io: @@ -209,8 +231,9 @@ Making a release The following GitHub checklist might be helpful in a release PR:: * [ ] update news and what's new date in master and release branch - * [ ] create tag - * [ ] twine the wheels to PyPI when that's green + * [ ] check that the wheels can be built successfully + * [ ] create tag on the main github repo (after merging the release PR) + * [ ] upload the wheels and source tarball to PyPI * [ ] https://github.com/scikit-learn/scikit-learn/releases draft * [ ] confirm bot detected at https://github.com/conda-forge/scikit-learn-feedstock and wait for merge From bc354dca299b9f6472d66bd4b64e65c49b077e58 Mon Sep 17 00:00:00 2001 From: Olivier Grisel Date: Wed, 2 Dec 2020 11:09:04 +0100 Subject: [PATCH 02/14] Update doc/developers/maintainer.rst Co-authored-by: Adrin Jalali --- doc/developers/maintainer.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/developers/maintainer.rst b/doc/developers/maintainer.rst index 3daf78f6f1d9b..ddb5058b89eae 100644 --- a/doc/developers/maintainer.rst +++ b/doc/developers/maintainer.rst @@ -177,7 +177,7 @@ Making a release workflow" form). 7. Alternatively, it's possible to collect locally the generated binary wheel - packages and source tarbakk and upload them all to PyPI by running the + packages and source tarball and upload them all to PyPI by running the following commands in the scikit-learn source folder (checked out at the release tag): From 58016c572dda7d844fc2046a85503589804ed76c Mon Sep 17 00:00:00 2001 From: Olivier Grisel Date: Wed, 2 Dec 2020 11:10:00 +0100 Subject: [PATCH 03/14] Update doc/developers/maintainer.rst --- doc/developers/maintainer.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/developers/maintainer.rst b/doc/developers/maintainer.rst index ddb5058b89eae..3ca242520ba91 100644 --- a/doc/developers/maintainer.rst +++ b/doc/developers/maintainer.rst @@ -75,7 +75,7 @@ should be excluded. For major releases, do not forget to prepare a Release Highlights page as a runnable example and check that its HTML rendering looks correct. These release -higlights should be linked from the ``whats_new.html`` file for the new version +higlights should be linked from the ``whats_new.rst`` file for the new version of scikit-learn. First, create a branch, **on your own fork** (to release e.g. `0.99.3`): From efd34088ed0aa8ade8fc4a49cbe187f2b3117912 Mon Sep 17 00:00:00 2001 From: Olivier Grisel Date: Wed, 2 Dec 2020 11:58:13 +0100 Subject: [PATCH 04/14] Apply suggestions from code review Co-authored-by: Chiara Marmo --- doc/developers/maintainer.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/doc/developers/maintainer.rst b/doc/developers/maintainer.rst index 3ca242520ba91..69bef12934f4c 100644 --- a/doc/developers/maintainer.rst +++ b/doc/developers/maintainer.rst @@ -75,7 +75,7 @@ should be excluded. For major releases, do not forget to prepare a Release Highlights page as a runnable example and check that its HTML rendering looks correct. These release -higlights should be linked from the ``whats_new.rst`` file for the new version +higlights should be linked from the ``doc/whats_new/v0.99.rst`` file for the new version of scikit-learn. First, create a branch, **on your own fork** (to release e.g. `0.99.3`): @@ -122,8 +122,7 @@ Making a release $ git shortlog -s 0.98.33.. | cut -f2- | sort --ignore-case | tr '\n' ';' | sed 's/;/, /g;s/, $//' - For major releases, make sure that the release highlights example is - properly linked from the ``doc/v0.99/whats_new.rst`` file. + - For major releases, link the release highlights example from the ``doc/whats_new/v0.99.rst`` file. - Update the release date in ``whats_new.rst`` @@ -154,8 +153,9 @@ Making a release Before building the wheels, make sure that the ``pyproject.toml`` file is up to date and using the oldest version of ``numpy`` for each Python version - to avoid ABI incompatibility issues. Moreover, a new line have to be included - in the ``pyproject.toml`` file for each new supported version of Python. + to avoid `ABI `_ + incompatibility issues. Moreover, a new line have to be included in the + ``pyproject.toml`` file for each new supported version of Python. 4. Once the CD has completed successfully, upload the generated artifacts (.tar.gz and .whl files) to https://test.pypi.org using the "Run workflow" From 773fefa47c092f7e4472e12a5a58bf5de0ce5e17 Mon Sep 17 00:00:00 2001 From: Olivier Grisel Date: Wed, 2 Dec 2020 14:58:48 +0100 Subject: [PATCH 05/14] Apply suggestions from code review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Juan Carlos Alfaro Jiménez Co-authored-by: Chiara Marmo --- doc/developers/maintainer.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/developers/maintainer.rst b/doc/developers/maintainer.rst index 69bef12934f4c..b0a1eb8cc8165 100644 --- a/doc/developers/maintainer.rst +++ b/doc/developers/maintainer.rst @@ -92,7 +92,7 @@ master!) with all the desired changes: git rebase -i upstream/0.99.2 -Do not forget to add a commit updating sklearn.__version__. +Do not forget to add a commit updating ``sklearn.__version__``. It's nice to have a copy of the ``git rebase -i`` log in the PR to help others understand what's included. @@ -114,13 +114,13 @@ Making a release the RC releases. These changes should be made in master and cherry-picked into the release branch, only before the final release. - - Edit the ``doc/v0.99/whats_new.rst`` file to add release title and list of + - Edit the ``doc/whats_new/v0.99.rst`` file to add release title and list of contributors. You can retrieve the list of contributor names with: :: - $ git shortlog -s 0.98.33.. | cut -f2- | sort --ignore-case | tr '\n' ';' | sed 's/;/, /g;s/, $//' + $ git shortlog -s 0.98.33.. | cut -f2- | sort --ignore-case | tr '\n' ';' | sed 's/;/, /g;s/, $//' | fold -s - For major releases, link the release highlights example from the ``doc/whats_new/v0.99.rst`` file. From f141f81084c354c7e9b078891d55e774b020e865 Mon Sep 17 00:00:00 2001 From: Olivier Grisel Date: Wed, 2 Dec 2020 15:52:58 +0100 Subject: [PATCH 06/14] Improve structure of the maintainers doc --- doc/developers/maintainer.rst | 100 ++++++++++++++++++++++++---------- 1 file changed, 70 insertions(+), 30 deletions(-) diff --git a/doc/developers/maintainer.rst b/doc/developers/maintainer.rst index b0a1eb8cc8165..90ed70d8f1da5 100644 --- a/doc/developers/maintainer.rst +++ b/doc/developers/maintainer.rst @@ -57,18 +57,49 @@ permissions given to maintainers, which includes: Preparing a release PR ...................... +Major version +~~~~~~~~~~~~~ + Releasing the first RC of e.g. version `0.99` involves creating the release branch `0.99.X` directly on the main repo, where `X` really is the letter X, -**not a placeholder**. This is considered the *feature freeze*. The -development for the major and minor releases of 0.99 should -**also** happen under `0.99.X`. Each release (rc, major, or minor) is a tag -under that branch. +**not a placeholder**. The development for the major and minor releases of 0.99 +should **also** happen under `0.99.X`. Each release (rc, major, or minor) is a +tag under that branch. + +This is done only once, as the major and minor releases happen on the same +branch: + + .. prompt:: bash $ + + git checkout -b 0.99.X + + Again, `X` is literal here, and `99` is replaced by the release number. + The branches are called ``0.19.X``, ``0.20.X``, etc. In terms of including changes, the first RC ideally counts as a *feature freeze*. Each coming release candidate and the final release afterwards will include only minor documentation changes and bug fixes. Any major enhancement or feature should be excluded. +Then you can prepare a local branch for the release itself, for instance: +``release-0.99.0rc1``, push it to your github fork and open a PR **to the** +`scikit-learn/0.99.X` **branch**. + +This PR will be used to push commits related to the release as explained in +:ref:`making_a_release`. + +You can also create a second PR from master and targeting master to increment +the ``__version__`` variable in `sklearn/__init__.py` to increment the dev +version. This means while we're in the release candidate period, the latest +stable is two versions behind the master branch, instead of one. In this PR +targeting master you should also include a new file for the matching version +under the ``doc/whats_new/`` folder so PRs that target the next version can +contribute their changelog entries to this file in parallel to the release +process. + +Minor version release +~~~~~~~~~~~~~~~~~~~~~ + The minor releases should include bug fixes and some relevant documentation changes only. Any PR resulting in a behavior change which is not a bug fix should be excluded. @@ -97,18 +128,13 @@ Do not forget to add a commit updating ``sklearn.__version__``. It's nice to have a copy of the ``git rebase -i`` log in the PR to help others understand what's included. +.. _making_a_release: + Making a release ................ -0. Create the release branch on the main repo, if it does not exist. This is - done only once, as the major and minor releases happen on the same branch: - - .. prompt:: bash $ - - git checkout -b 0.99.X - - Again, `X` is literal here, and `99` is replaced by the release number. - The branches are called ``0.19.X``, ``0.20.X``, etc. +0. Ensure that you have checkouted the branch of the release PR as explained + :ref:`preparing_a_release_pr` above. 1. Update docs. Note that this is for the final release, not necessarily for the RC releases. These changes should be made in master and cherry-picked @@ -130,16 +156,14 @@ Making a release front page (with the release month as well). 2. On the branch for releasing, update the version number in - `sklearn/__init__.py`, the ``__version__`` variable by removing ``dev*`` - only when ready to release. On master, increment the version in the same - place (when branching for release). This means while we're in the release - candidate period, the latest stable is two versions behind the master - branch, instead of one. - -3. Proceed with caution. Ideally, tags should be created when you're almost - certain that the release is ready, since adding a tag to the main repo can - trigger certain automated processes. You can create a PR in the main repo - and trigger the wheel builder with the ``[cd build]`` commit marker using + ``sklearn/__init__.py``, the ``__version__``. + + For major releases, please add a 0 add the end: 0.99.0 instead of 0.99. + + For a first release candidates, use the rc1 suffix on the expected final + release number: 0.99.0rc1. + +3. Trigger the wheel builder with the ``[cd build]`` commit marker using the command: .. prompt:: bash $ @@ -157,20 +181,36 @@ Making a release incompatibility issues. Moreover, a new line have to be included in the ``pyproject.toml`` file for each new supported version of Python. -4. Once the CD has completed successfully, upload the generated artifacts - (.tar.gz and .whl files) to https://test.pypi.org using the "Run workflow" - form for the following GitHub Actions workflow: +.. note:: + + The acronym CD in `[cd build]` stands for `Continuous Delivery + `_ and refers to the + automation used to generate the release artifacts (binary and source + packages). This can be seen as an extension to CI which stands for + `Continuous Integration + `_. The CD workflow on + GitHub Actions is also used to automatically build and publish packages for + the developement branch of scikit-learn every night. See + :ref:`install_nightly_builds`. + +4. Once all the CD jobs have completed successfully, upload the generated + artifacts (.tar.gz and .whl files) to https://test.pypi.org using the "Run + workflow" form for the following GitHub Actions workflow: https://github.com/scikit-learn/scikit-learn/actions?query=workflow%3A%22Publish+to+Pypi%22 +5. If this went fine, you can proceed with tagging. Proceed with caution. + Ideally, tags should be created when you're almost certain that the release + is ready, since adding a tag to the main repo can trigger certain automated + processes. -5. If this went fine, you can proceed with tagging. Create the tag and push it (if - it's an RC, it can be ``0.xxrc1`` for instance): + Create the tag and push it (if it's an RC, it can be ``0.xx.0rc1`` for + instance): .. prompt:: bash $ - git tag -a 0.99 # in the 0.99.X branch - git push git@github.com:scikit-learn/scikit-learn.git 0.99 + git tag -a 0.99.0 # in the 0.99.X branch + git push git@github.com:scikit-learn/scikit-learn.git 0.99.0 6. Trigger the GitHub Actions workflow again but this time to upload the artifacts to the real https://pypi.org (replace "testpypi" by "pypi" in the "Run From 4e973c71f241d511016030bff94b28dc0399d26c Mon Sep 17 00:00:00 2001 From: Olivier Grisel Date: Wed, 2 Dec 2020 15:57:39 +0100 Subject: [PATCH 07/14] Cosmetics --- doc/developers/maintainer.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/developers/maintainer.rst b/doc/developers/maintainer.rst index 90ed70d8f1da5..8ff1c41f684ec 100644 --- a/doc/developers/maintainer.rst +++ b/doc/developers/maintainer.rst @@ -106,8 +106,8 @@ should be excluded. For major releases, do not forget to prepare a Release Highlights page as a runnable example and check that its HTML rendering looks correct. These release -higlights should be linked from the ``doc/whats_new/v0.99.rst`` file for the new version -of scikit-learn. +higlights should be linked from the ``doc/whats_new/v0.99.rst`` file for the +new version of scikit-learn. First, create a branch, **on your own fork** (to release e.g. `0.99.3`): From d0e692bb70e092518233427762d1477ef4b8a43a Mon Sep 17 00:00:00 2001 From: Olivier Grisel Date: Wed, 2 Dec 2020 16:56:53 +0100 Subject: [PATCH 08/14] update the checklist and cross-reference it --- doc/developers/maintainer.rst | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/doc/developers/maintainer.rst b/doc/developers/maintainer.rst index 8ff1c41f684ec..4fec46e9904e6 100644 --- a/doc/developers/maintainer.rst +++ b/doc/developers/maintainer.rst @@ -83,7 +83,8 @@ or feature should be excluded. Then you can prepare a local branch for the release itself, for instance: ``release-0.99.0rc1``, push it to your github fork and open a PR **to the** -`scikit-learn/0.99.X` **branch**. +`scikit-learn/0.99.X` **branch**. Copy the :ref:`release_checklist` templates +in the description of the Pull Request to track progress. This PR will be used to push commits related to the release as explained in :ref:`making_a_release`. @@ -123,6 +124,9 @@ master!) with all the desired changes: git rebase -i upstream/0.99.2 +Copy the :ref:`release_checklist` templates in the description of the Pull +Request to track progress. + Do not forget to add a commit updating ``sklearn.__version__``. It's nice to have a copy of the ``git rebase -i`` log in the PR to help others @@ -268,11 +272,18 @@ Making a release git commit -m "Update stable to point to 0.999" git push origin master +.. _release_checklist: + +Release checklist +................. + The following GitHub checklist might be helpful in a release PR:: * [ ] update news and what's new date in master and release branch * [ ] check that the wheels can be built successfully - * [ ] create tag on the main github repo (after merging the release PR) + * [ ] upload the wheels and source tarball to https://test.pypi.org + * [ ] merge the release PR in the release branch + * [ ] create tag on the main github repo * [ ] upload the wheels and source tarball to PyPI * [ ] https://github.com/scikit-learn/scikit-learn/releases draft * [ ] confirm bot detected at From ce10a7dbaea2fb18ca29374bc34c66d655eb2398 Mon Sep 17 00:00:00 2001 From: Olivier Grisel Date: Wed, 2 Dec 2020 17:04:08 +0100 Subject: [PATCH 09/14] Refine checklist --- doc/developers/maintainer.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/doc/developers/maintainer.rst b/doc/developers/maintainer.rst index 4fec46e9904e6..df2b53c94c96d 100644 --- a/doc/developers/maintainer.rst +++ b/doc/developers/maintainer.rst @@ -279,8 +279,9 @@ Release checklist The following GitHub checklist might be helpful in a release PR:: - * [ ] update news and what's new date in master and release branch - * [ ] check that the wheels can be built successfully + * [ ] update news and what's new date in release branch + * [ ] update news and what's new date and sklearn dev0 version in master branch + * [ ] check that the for the release wheels can be built successfully * [ ] upload the wheels and source tarball to https://test.pypi.org * [ ] merge the release PR in the release branch * [ ] create tag on the main github repo From 239d4b2e6c44e0e067eba3fb44a0dfc949e11e7a Mon Sep 17 00:00:00 2001 From: Olivier Grisel Date: Wed, 2 Dec 2020 17:20:48 +0100 Subject: [PATCH 10/14] Fix bug in ordering --- doc/developers/maintainer.rst | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/doc/developers/maintainer.rst b/doc/developers/maintainer.rst index df2b53c94c96d..0f613db23b03e 100644 --- a/doc/developers/maintainer.rst +++ b/doc/developers/maintainer.rst @@ -197,9 +197,13 @@ Making a release the developement branch of scikit-learn every night. See :ref:`install_nightly_builds`. -4. Once all the CD jobs have completed successfully, upload the generated - artifacts (.tar.gz and .whl files) to https://test.pypi.org using the "Run - workflow" form for the following GitHub Actions workflow: +4. Once all the CD jobs have completed successfully in the PR, merge it, + again with the `[cd build]` marker in the commit message. This time + the results will be uploaded to the staging area. + + You should then be able to upload the generated artifacts (.tar.gz and .whl + files) to https://test.pypi.org using the "Run workflow" form for the + following GitHub Actions workflow: https://github.com/scikit-learn/scikit-learn/actions?query=workflow%3A%22Publish+to+Pypi%22 @@ -282,8 +286,8 @@ The following GitHub checklist might be helpful in a release PR:: * [ ] update news and what's new date in release branch * [ ] update news and what's new date and sklearn dev0 version in master branch * [ ] check that the for the release wheels can be built successfully + * [ ] merge the PR with `[cd build]` commit message to upload wheels to the staging repo * [ ] upload the wheels and source tarball to https://test.pypi.org - * [ ] merge the release PR in the release branch * [ ] create tag on the main github repo * [ ] upload the wheels and source tarball to PyPI * [ ] https://github.com/scikit-learn/scikit-learn/releases draft From a59b3bf04d6de5e1cc3f46178ec7df3e1486340e Mon Sep 17 00:00:00 2001 From: Olivier Grisel Date: Wed, 2 Dec 2020 19:29:55 +0100 Subject: [PATCH 11/14] Move paragraph + more explicit branching commands --- doc/developers/maintainer.rst | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/doc/developers/maintainer.rst b/doc/developers/maintainer.rst index 0f613db23b03e..e18ea3e93e344 100644 --- a/doc/developers/maintainer.rst +++ b/doc/developers/maintainer.rst @@ -60,6 +60,11 @@ Preparing a release PR Major version ~~~~~~~~~~~~~ +Prior to branching please do not forget to prepare a Release Highlights page as +a runnable example and check that its HTML rendering looks correct. These +release higlights should be linked from the ``doc/whats_new/v0.99.rst`` file +for the new version of scikit-learn. + Releasing the first RC of e.g. version `0.99` involves creating the release branch `0.99.X` directly on the main repo, where `X` really is the letter X, **not a placeholder**. The development for the major and minor releases of 0.99 @@ -71,7 +76,11 @@ branch: .. prompt:: bash $ + # Assuming upstream is an alias for the main scikit-learn repo: + git fetch uptream master + git checkout uptream/master git checkout -b 0.99.X + git push --set-upstream uptream 0.99.X Again, `X` is literal here, and `99` is replaced by the release number. The branches are called ``0.19.X``, ``0.20.X``, etc. @@ -105,11 +114,6 @@ The minor releases should include bug fixes and some relevant documentation changes only. Any PR resulting in a behavior change which is not a bug fix should be excluded. -For major releases, do not forget to prepare a Release Highlights page as a -runnable example and check that its HTML rendering looks correct. These release -higlights should be linked from the ``doc/whats_new/v0.99.rst`` file for the -new version of scikit-learn. - First, create a branch, **on your own fork** (to release e.g. `0.99.3`): .. prompt:: bash $ From 73ac6f35620f1a9b217c0ca350669685a2af5068 Mon Sep 17 00:00:00 2001 From: Olivier Grisel Date: Wed, 2 Dec 2020 19:32:27 +0100 Subject: [PATCH 12/14] Apply suggestions from code review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Juan Carlos Alfaro Jiménez --- doc/developers/maintainer.rst | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/doc/developers/maintainer.rst b/doc/developers/maintainer.rst index e18ea3e93e344..eeda592bc6326 100644 --- a/doc/developers/maintainer.rst +++ b/doc/developers/maintainer.rst @@ -57,15 +57,15 @@ permissions given to maintainers, which includes: Preparing a release PR ...................... -Major version -~~~~~~~~~~~~~ +Major version release +~~~~~~~~~~~~~~~~~~~~~ Prior to branching please do not forget to prepare a Release Highlights page as a runnable example and check that its HTML rendering looks correct. These release higlights should be linked from the ``doc/whats_new/v0.99.rst`` file for the new version of scikit-learn. -Releasing the first RC of e.g. version `0.99` involves creating the release +Releasing the first RC of e.g. version `0.99.0` involves creating the release branch `0.99.X` directly on the main repo, where `X` really is the letter X, **not a placeholder**. The development for the major and minor releases of 0.99 should **also** happen under `0.99.X`. Each release (rc, major, or minor) is a @@ -141,8 +141,8 @@ understand what's included. Making a release ................ -0. Ensure that you have checkouted the branch of the release PR as explained - :ref:`preparing_a_release_pr` above. +0. Ensure that you have checked out the branch of the release PR as explained + in :ref:`preparing_a_release_pr` above. 1. Update docs. Note that this is for the final release, not necessarily for the RC releases. These changes should be made in master and cherry-picked @@ -166,9 +166,9 @@ Making a release 2. On the branch for releasing, update the version number in ``sklearn/__init__.py``, the ``__version__``. - For major releases, please add a 0 add the end: 0.99.0 instead of 0.99. + For major releases, please add a 0 at the end: 0.99.0 instead of 0.99. - For a first release candidates, use the rc1 suffix on the expected final + For the first release candidate, use the rc1 suffix on the expected final release number: 0.99.0rc1. 3. Trigger the wheel builder with the ``[cd build]`` commit marker using From b3e86ec0903b5e94d51b1a095941cb6b17efb3a9 Mon Sep 17 00:00:00 2001 From: Olivier Grisel Date: Thu, 3 Dec 2020 00:03:40 +0100 Subject: [PATCH 13/14] Update doc/developers/maintainer.rst MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Juan Carlos Alfaro Jiménez --- doc/developers/maintainer.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/developers/maintainer.rst b/doc/developers/maintainer.rst index eeda592bc6326..bd43365b24c11 100644 --- a/doc/developers/maintainer.rst +++ b/doc/developers/maintainer.rst @@ -197,8 +197,8 @@ Making a release packages). This can be seen as an extension to CI which stands for `Continuous Integration `_. The CD workflow on - GitHub Actions is also used to automatically build and publish packages for - the developement branch of scikit-learn every night. See + GitHub Actions is also used to automatically create nightly builds and + publish packages for the developement branch of scikit-learn. See :ref:`install_nightly_builds`. 4. Once all the CD jobs have completed successfully in the PR, merge it, From eaea67403398944d64d729b337427110e3702e0c Mon Sep 17 00:00:00 2001 From: Olivier Grisel Date: Thu, 3 Dec 2020 10:12:21 +0100 Subject: [PATCH 14/14] Apply suggestions from code review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Juan Carlos Alfaro Jiménez --- doc/developers/maintainer.rst | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/developers/maintainer.rst b/doc/developers/maintainer.rst index bd43365b24c11..03072185f8479 100644 --- a/doc/developers/maintainer.rst +++ b/doc/developers/maintainer.rst @@ -62,12 +62,12 @@ Major version release Prior to branching please do not forget to prepare a Release Highlights page as a runnable example and check that its HTML rendering looks correct. These -release higlights should be linked from the ``doc/whats_new/v0.99.rst`` file +release highlights should be linked from the ``doc/whats_new/v0.99.rst`` file for the new version of scikit-learn. Releasing the first RC of e.g. version `0.99.0` involves creating the release branch `0.99.X` directly on the main repo, where `X` really is the letter X, -**not a placeholder**. The development for the major and minor releases of 0.99 +**not a placeholder**. The development for the major and minor releases of `0.99` should **also** happen under `0.99.X`. Each release (rc, major, or minor) is a tag under that branch. @@ -77,10 +77,10 @@ branch: .. prompt:: bash $ # Assuming upstream is an alias for the main scikit-learn repo: - git fetch uptream master - git checkout uptream/master + git fetch upstream master + git checkout upstream/master git checkout -b 0.99.X - git push --set-upstream uptream 0.99.X + git push --set-upstream upstream 0.99.X Again, `X` is literal here, and `99` is replaced by the release number. The branches are called ``0.19.X``, ``0.20.X``, etc. @@ -166,10 +166,10 @@ Making a release 2. On the branch for releasing, update the version number in ``sklearn/__init__.py``, the ``__version__``. - For major releases, please add a 0 at the end: 0.99.0 instead of 0.99. + For major releases, please add a 0 at the end: `0.99.0` instead of `0.99`. - For the first release candidate, use the rc1 suffix on the expected final - release number: 0.99.0rc1. + For the first release candidate, use the `rc1` suffix on the expected final + release number: `0.99.0rc1`. 3. Trigger the wheel builder with the ``[cd build]`` commit marker using the command: