@@ -9,14 +9,9 @@ if the added benefit is worth the effort of adapting existing code.
9
9
10
10
Because we are a visualization library, our primary output is the final
11
11
visualization 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 aesthetic,
13
13
are backwards-incompatible API changes.
14
14
15
- .. toctree ::
16
- :hidden:
17
-
18
- color_changes.rst
19
-
20
15
21
16
Add new API and features
22
17
------------------------
@@ -37,6 +32,25 @@ take particular care when adding new API:
37
32
__ https://emptysqua.re/blog/api-evolution-the-right-way/#adding-parameters
38
33
39
34
35
+ .. _color-changes :
36
+
37
+ Add or change colormaps, color sequences, and styles
38
+ ----------------------------------------------------
39
+ Visual changes are considered an API break. Therefore, we generally do not modify
40
+ existing colormaps, color sequences, or styles.
41
+
42
+ We put a high bar on adding new colormaps and styles to prevent excessively growing
43
+ them. While decision is case-by-case, evaluation criteria include:
44
+
45
+ - novelty: Does it support a new use case? e.g. slight variations of existing maps,
46
+ sequences and styles or yet "another divergent colormap" are likely not accepted
47
+ - usability: Are colors of sequences sufficiently distinct? Has colorblindness
48
+ been considered?
49
+ - evidence of wide spread usage: for example academic papers, industry blogs and
50
+ whitepapers, or inclusion in other visualization libraries or domain specific tools
51
+ - open license: colormaps, sequences, and styles must have a BSD compatible license
52
+ (see :ref: `license-discussion `)
53
+
40
54
.. _deprecation-guidelines :
41
55
42
56
Deprecate API
0 commit comments