Skip to content

Track ggplot2 version in plot#6772

Draft
teunbrand wants to merge 3 commits intotidyverse:mainfrom
teunbrand:version_information
Draft

Track ggplot2 version in plot#6772
teunbrand wants to merge 3 commits intotidyverse:mainfrom
teunbrand:version_information

Conversation

@teunbrand
Copy link
Collaborator

This PR aims to fix #6714.

Whenever a plot is created, the new version property is populated with the current version.
If a plot is to be rendered, an error is thrown if the plot's version is not the same as the current version.
This should typically occur when a plot has been saved to disk with a prior version of ggplot2, and now no longer works.

There are a few open questions:

  • Should we do this at all?
  • Should we throw a warning instead of an error?

We can also do a revdepcheck to weed out all the packages that misbehave.

@teunbrand teunbrand marked this pull request as draft December 10, 2025 15:17
@aphalo
Copy link
Contributor

aphalo commented Feb 5, 2026

@teunbrand Hi Teun! This is an interesting question. If you decide to implement this, I suggest using a warning, unless you are sure all old plots will not render at all. Sometimes, it can be useful to get some idea of what a plot is about, even if inperfectly rendered. Another thought is that it would be better to use "object versions" than 'ggplot2' versions. Why issue an error for a change from version 4.0.1 to 4.0.2? I would change the label only when there is a significant compatibility break. In such a case, the warning (or error), could give the 'ggplot2' versions that can render the object as a range, which would be a lot friendlier to users in the case they cannot rebuild the object.
I (almost) never save ggplot objects to disk. So, as you mentioned in #6714, the main solution is to discourage users from saving these objects to disk. However, nothing prevents users from saving objects or expecting this to work, say sharing a ggplot object with somone who does not have the code to regenearte it. Another possible situation is a user working interactively at the command prompt, saving the R workspace, and expecting to be able to render the objects in the workspace at a later time, possibly after an update to 'ggplot2'. So I think that a coarser grained test, triggering an error only when rendering is not possible would be more helpful. (I am assuming rendering is possible at least across minor versions.)

@teunbrand
Copy link
Collaborator Author

Thanks for your thoughts Pedro! I get that this would be easier from a user perspective, but from a maintenance point of view it'd become tedious to test and verify if there is between-version compatibility and doing the bookkeeping. It is not even guaranteed for minor version updates. People can share plots with themselves and oneanother as data + code, or as graphics, but shouldn't do this as ggplot objects.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Version info stored and can be queries in ggplot object

2 participants