-
-
Notifications
You must be signed in to change notification settings - Fork 25.8k
0.20postrc again #12151
0.20postrc again #12151
Conversation
…-learn#11946) 'interesting' isn't directly supported by the following claim (i.e., that joblib can be more efficient than pickle), and also describing this as interesting isn't very useful to the user in my opinion.
… / making use of sparse threshold (scikit-learn#11958)
Minor reorder of the imports as well.
…12001) Previously these assertions would pass without matching.
Instead of adding an `if` to check for values that become the new max, simply use `fmax` to get the maximum and update the value. This improves readability. It may improve performance as `fmax` can be a single assembly instruction. Though most compilers can probably figure this out anyways.
…it-learn#12011) Some IDEs such as VS Code use the pytest command to collect all the tests of the workspace in the background. This can cause unexpected execution of arbitrary Python scripts in the workspace (examples, benchmarks...). The doc folder is also ignored because it has python scripts for sphinx along with copies of the examples. To safely run pytest in the doc folder, we need to used the find command to find all "*.rst" files as done in the project Makefile.
Avoid requiring internet for test suite. Examples will still run with internet (as long as cache is occasionally cleared).
The descriptions were the wrong way around
…n#12114) * Be more specific about logistic regression solver in examples * Use early stopped SGD (faster) and plot cross-validated error for best models * Fix LR solver in /plot_voting_probas.pyexamples/ensemble/plot_voting_probas.py * Fix LR solver & scale data in plot_digits_classification_exercise.py * Use saga solver in plot_logistic_l1_l2_sparsity.py * Use LBFGS solver in plot_iris_logistic.py * Use LBFGS in plot_logistic.py * Use SAGA solver for Logistic Regression Path example * Use LBFGS solver in plot_classifier_chain_yeast.py * Use LBFGS solver in plot_rbm_logistic_classification.py * typo * typo * Bump up pandas dependency to 0.17.1 * Bump up examples minimal deps to match pandas 0.17.1 * Fix figure layout for plot_digits_pipe.py * Version numbers are not decimal numbers * Set multinomial, no scaling to keep example simple, fix formatting of example doc * Missing plt.tight_layout() in plot_voting_probas.py * Missing plt.tight_layout() in plot_logistic.py
|
oh no, I did "Squash and merge".... Should I redo that? |
|
It might be a bit hard to know what is part or not of the 0.20.X without the git logs. Do you think it's would be too bad to revert, re-add the commits and move the tag (since it's not on PyPi yet)? |
|
I guess we also need to list the contributors, right? |
|
@amueller I wanted to say: I would redo it, it should not be much work as you can re-use the branch of this PR. But I see you actually released (added a tag and pushed it to github) in the meantime? |
|
I would argue that even force pushing a tag on 0.20.X to a new commit, is less problematic than not preserving git history. Particularly given that, informally, this is going to be a long term maintenance branch.. |
|
and if we do that, we can at once still include a fix for the major regression @glemaitre found: #12155 |
|
FYI, I've merged #12155 |
|
+1 to rewrite the history of the 0.20.X branch and redoing the tag to also include #12155. |
|
So I think there is agreement between @glemaitre, @rth, @ogrisel and me to re-do the tag / release ? (assuming we can undo the github release) I can make a new version of this PR if needed. |
I'll vote +1 if we can. |
|
I've been AFK a couple of days and have no idea what's going on here. Personally, given the size of the change list, I would've considered releasing this as rc2 and waited a couple of days before closing off 0.20. |
|
I also note that there is no list of contributors to 0.20 in |
|
rc2 is also an option, but in any case that also means removing the current tag and re-doing the last part of the 0.20.x branch |
|
In his last comment Andy didn't seem opposed to re-doing it, someone should just make it happen. Regarding rc2, to do you think it would be much worse to do a 0.20 closely followed by a 0.20.1, rather than rc2, then 0.20, then 0.20.1 ? Given the amount of changes, there might be some regressions, but wouldn't it be better to discover it earlier than later: I'm not sure what percentage of users actually test the RC, and how representative the feedback on RC's is? I would be +1 to make a release directly without rc2, otherwise feedback time + the fact that we will inevitably discover new bugs will shift the release by another couple of weeks. Also even people who usually test RC's might be reluctant to test it a second time in the same month. |
|
@jnothman I got back from a trip and decided it's time to release is what happened. And then I accidentally squashed these commits. I'm gonna undo the squashes and redo everything. I'm also tending towards a 0.20. We will get much more feedback that way. |
|
done (i.e. force-pushed the actual commits into 0.20.0 and retagged). I'm going to make the changes for the CI / build stuff now. |
|
@amueller can you wait a moment with tagging again? (or undo that again) there are some additional things that should go in (and can be done right now, I mean, without needing to wait more days) |
|
BTW, also +1 on doing final 0.20.0 instead of 0.20rc2 |
|
I included #12155. anything else? |
|
We need to generate the contributor list. |
|
Maybe the dev gitter is a bit easier for quick chatting, but I added there: update whats_new as @jnothman noted above, and update the version in |
Continuation of #11948