As user of the pgfplots
software, I do not want to risk that a package update leads to a different outcome of my existing images. Consequently, I would like to have an opportunity to "preserve" my output even if the package author decides to change something for "new" documents. The alternative would be to browse through entire documents to see if any "obvious" change has occurred. I expect that such changes do not happen, even if an isolated view on the image clearly confirms that a change was caused by a bugfix.
On the other hand, I as author of pgfplots
need the freedom to make changes to the software, either because of new features or in order to fix bugs. I have an interest in maintaining existing workarounds created by users, either those derived because pgfplots
lacked support for something or because pgfplots
had a bug. A package update should not invalidate old work-arounds, but it should provide a fix for all those users who "started a document from scratch".
Choosing a suitable \pgfplotsset{compat=<version>}
flag is a solution which addresses both use-cases, and the fact that pgfplots
suggests a suitable value for <version>
should make it simpler to choose it.
However, the choice compat=newest
spoils both use-cases: both suffer seriously.
There may be a scenario in which backwards compatibility is of minor importance - this is where compat=newest
has a use-case. Personally, I do not know what the use-case might be. The choice compat=newest
means "I do not care if my old figures change in appearance after the next version upgrade".
Over time Christian fixed a lot of things regarding the tick labels, some originating from questions asked here, some from constant abusers like myself and other users here.
There is not only one tick label related issue here. In every version loads of tiny changes are introduced however if you don't use the latest set of features, there might be discrepancies. Examples of such entries can be found in changelog file.
2010-09-08 Christian Feuersaenger <ludewich@users.sourceforge.net>
- added 'table/every nth row' key
- fixed bug: now, extra tick labels can have a different 'ticklabel pos'
than the original axes (it was broken since 1.2.2)
- fixed bug: it is now allowed to provide '#' (hash sign) in \addplot
option arguments (for example to define 'x filter/.code={...#1...}')
- added support for \pgfplotsforeachungrouped \a/\b in {...} syntax
..........................
2010-07-09 Christian Feuersaenger <ludewich@users.sourceforge.net>
- fixed bug: the check whether lists are terminated by '\\' failed if '\\'
occured within the list. This affected mainly legends and tick label
lists.
- improved and documented customized legends, including optional
appearance keys for specific legend texts
|\addlegendentry[<options>]{<text>}| and documentation for multiline
legend entries.
.........................
2009-12-02 Christian Feuersaenger <ludewich@users.sourceforge.net>
- found and fixed bug: tick labels could penetrate the axis. This should
no longer happen.
etc. And probably it is much more involved than these items that made it to the changelog. Thus, it is very unlikely that you have something regarding that warning.
There is a great effort for keeping the backwards compatibility but there is always one archaic distro that still has pre 1.3 version and in my opinion they should be updated instead keeping this much of effort to maintain backwards compatibility.
Best Answer
Run your document without
\pgfplotsset{compat=...}
In the log you will get:
The newest version is the one suggested in the log:
\pgfplotsset{compat=1.18}
.