@@ -9,14 +9,9 @@ if the added benefit is worth the effort of adapting existing code.
99
1010Because we are a visualization library, our primary output is the final
1111visualization the user sees; therefore, the appearance of the figure is part of
12- the API and any changes, either semantic or :ref: `aesthetic <color_changes >`,
12+ the API and any changes, either semantic or :ref: `aesthetic <color-changes >`,
1313are backwards-incompatible API changes.
1414
15- .. toctree ::
16- :hidden:
17-
18- color_changes.rst
19-
2015
2116Add new API and features
2217------------------------
@@ -37,6 +32,27 @@ take particular care when adding new API:
3732 __ https://emptysqua.re/blog/api-evolution-the-right-way/#adding-parameters
3833
3934
35+ .. _color-changes :
36+
37+ Add or change colormaps and styles
38+ ----------------------------------
39+ Visual changes are considered an API break. Generally, we do not modify existing
40+ colormaps or styles.
41+
42+ We put a high bar on new colormaps and styles to prevent excessively growing them.
43+ Decision is case by case, but in general:
44+
45+ - new styles and colormaps should bring something new to the table, not just being
46+ a slight variation of what's already available in Matplotlib.
47+ - colorblindness and - in case of colormaps - perceptual uniformity should have
48+ been considered.
49+ - colormaps should have a track record, i.e. have been officially published
50+ somewhere and have proven usage scenarios.
51+ - copyright must be considered. Some commercial visualization tools claim
52+ rights on their styles. We we cannot include them if the legal situation is
53+ unclear.
54+
55+
4056.. _deprecation-guidelines :
4157
4258Deprecate API
0 commit comments