-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Breaking (and other) changes for dplyr 0.9.0 #2790
Labels
breaking change ☠️
API change likely to affect existing code
feature
a feature request or enhancement
verbs 🏃♀️
Milestone
Comments
krlmlr
changed the title
Breaking changes for dplyr 0.7.0
Breaking (and other) changes for dplyr 0.7.0, after dplyr 0.6.0 release
May 23, 2017
We'll reserve breaking API changes for 0.9.0. Maybe it would be better to have a label than a meta issue? |
krlmlr
changed the title
Breaking (and other) changes for dplyr 0.7.0, after dplyr 0.6.0 release
Breaking (and other) changes for dplyr 0.9.0
Jun 13, 2017
I'm not sure. They lie around here peacefully, waiting patiently for their time to come... |
👏 🙏 |
|
This old issue has been automatically locked. If you believe you have found a related problem, please file a new issue (with reprex) and link to this issue. https://reprex.tidyverse.org/ |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
breaking change ☠️
API change likely to affect existing code
feature
a feature request or enhancement
verbs 🏃♀️
I'd like to suggest that we break the things we want to break very early in the release cycle. We should only break things where there is a clearly better alternative in the existing CRAN version. This could be done in a separate pull request first, with early notification to the downstream dependencies.
New interfaces should not break existing ones, we can mark them as deprecated in the docs and start breaking them in the version after that. This includes changes in behavior.
This meta-issue could collect the scheduled breakages. Off the top of my head, this includes:
all.equal()
(all.equal() problems #2751)vars
attribute is a list (Compatibility fix for deserialized grouped dfs #2786 (comment))summarise_each()
andmutate_each()
(Deprecation messages #2791)rbind_list()
andrbind_all()
(Correctly handle empty names in arguments to bind_rows() #2828 (comment))distinct()
#3140na_matches
argumentdata.frame
, with an internalreconstruct()
that restores the"tbl_df"
class if the input had it (Use vctrs::vec_restore to preserve data frame subclass and attributes #3429)if_else()
andcase_when()
(if_else converts matrix into vector (unlike base::ifelse) #3256)The text was updated successfully, but these errors were encountered: