Release 4.0.0 #4388
Release 4.0.0 #4388
Conversation
…features Merge master into features
…-cache-move-to-session move Bestrelpath cache move to session
Handle os.chdir() during collection
Conflicts: src/_pytest/main.py
Merge master into features
Fix/improve handling of chdir with no-args and testpaths
cache_dir: use $TOX_ENV_DIR/ prefix if set
Merge master into features
Node: do not add "::()" to nodeid
To keep existing tests which emit RemovedInPytest4Warnings running, decided to go with a command line option because: * Is harder to integrate an ini option with tests which already use an ini file * It also marks tests which need to be removed/updated in 4.1, when RemovedInPytest4Warning and related functionality are removed. Fix pytest-dev#3737
Otherwise the tests will use tox's env cache which makes them flaky
…s-errors Change RemovedInPytest4Warnings to errors by default
pytester: pop TOX_ENV_DIR from os.environ
…features Merge master into features (about to prepare 4.0)
|
Also #4381 (merged to master later) would be nice to have. |
|
@blueyed there will be a few more majors to come after this one that wont have long delays |
Codecov Report
@@ Coverage Diff @@
## master #4388 +/- ##
==========================================
+ Coverage 95.9% 95.91% +0.01%
==========================================
Files 111 111
Lines 24938 24992 +54
Branches 2431 2439 +8
==========================================
+ Hits 23916 23972 +56
+ Misses 724 723 -1
+ Partials 298 297 -1
Continue to review full report at Codecov.
|
Good points. Let me explain the reasons why we would like to release 4.0 right away: In the past all our major releases (well, the two major releases) introduced sweeping and large changes, which makes users nervous to upgrade and makes it hard to pinpoint regressions when there are too many changes in place at the same time. 4.0 is a backward compatibility breakage already because all warnings are now errors, so we should reduce the "moving parts" in the release, that's why I would like to have a 4.0 release with as few things as possible, preferably only warnings changing into errors would be ideal IMO. Also, with 4.0 released, we are free to cleanup and remove the old deprecated functionality in Finally, as @RonnyPfannschmidt mentions, nothing prevents us to have a 4.1 release soon (like next week) if we want to: frequent minor releases means features reaching users faster. Of course minor releases also often mean unintended regressions, but as we improve our processes and codebase, my feeling is that those will tend to diminish and disappear (hopefully). Let me know if you still would like to see a 4.0 next week with the pdb features you are cooking up (which are awesome btw), but I would rather we stick to having a small 4.0 release.
Actually, we ideally should only break things if we can deprecate first for two minor releases. Small changes which are not API breakages are fine between minor releases. 😁 |
🎉