-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Initial infrastructure for editions: attempt 2 #6756
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
base: main
Are you sure you want to change the base?
Conversation
thomasp85
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
|
There was some useful feedback from the chat I had with the team on Monday. |
|
@thomasp85 Do you think we need to export just the setter, or also other helpers? |
This PR aims to adress a topic discussed off-github and replaces #6203.
Compared to #6203, this edition infrastructure is simpler. In this PR, we're not tracking parallel editions set by packages; it is only controlled by the user. It has two arms: the carrot and the stick.
The carrot is
edition_require(), which we can use to gatekeep new features tempting users to opt-in the newer editions.The stick is build into the
deprecate()function from #6733 and the newsupersede()function, meaning that superseded and deprecated functions become unavailable when the new edition is set.Broadly, I'm still skeptical of the edition concept. What we really want is to clean up the codebase and remove code we no longer recommend and make maintaining ggplot2 easier. The main thing preventing this goal is that the code in question is still in use by packages and in people's scripts. However, what editioning really seems to do is put additional maintenance burden around lifecycle management without achieving the main benefit of removing the code.