I am actually not sure whether this PR is preferrable compared to setting explicitly the minor version in .binder/requirements.txt.

• setting minor version in .binder/requirements. pros: more explicit, cons: more manual so more likely to be forgotten
• not setting minor version in .binder/requirements. pros: no need to change .binder/requirements, cons: in principle, there are some edge cases like the one detailed below where the version of scikit-learn may not be the correct one.

Reminder: the binder docker image depends on the last commit in the 0.22.X branch (the commit hash is used as a cache key for the docker images). If someone clicks on the binder link and the last commit in 0.22.X has changed, the docker image will be rebuilt. There is a edge case where the timeline goes like this:

• last commit on 0.22.X for some time
• someone clicks on the binder link
• 0.22.1 is released on PyPI

In this case 0.22.1 will be the version in the binder docker image until there is a new commit in the 0.22.X branch.

So the risk is that binder will offer the previous release (because that's what was available on pypi when the binder was last loaded) until the branch is updated?
One way to do this is to update the version manually and have the docker build fail until pypi is in sync with the docs

Another solution might change the release process such that the circle docs are only rendered once the release is on pypi... But not sure what the right way to engineer this is. And not sure it satisfies other requirements

A question @lesteve, sorry if I'm wrong
Imaging that the time line goes like this:
(1) scikit-learn release version sk_a, at the mean time, the latest numpy release is np_a
(1) scikit-learn release version sk_b, at the mean time, the latest numpy release is np_b
Of cource sk_a is compatible with np_a and sk_b is compatible with np_b, but we can't ensure that sk_a is compatible with np_b (e.g., we might remove some deprecated numpy functions).
So perhaps we should specify the version of all the dependencies?

Sorry I forgot about this one:

• I think it is probably simpler to explicitly set the scikit-learn version in .binder/requirements.txt as is currently done in the 0.22.X. We will have to add this manual step to the "how to make a release" documentation.
• I did set the dependencies version explicitly. I used roughly the latest version available at the time of 0.22 release