We should have an explicit EOL policy guide and, potentially, an explicit support matrix. We can then move version numbers out of other docs.
Currently available:
Graphistry EOL policy is:
- API deprecation:
-- Avoid most deprecations by making new APIs additive vs. breaking
-- Aim for 1+ year notification window when unavoidable
-- Ex: We still support our 1.0 REST protocol, and are only now moving to officially deprecate it
- Fixes go into new versions (vs. LTS patching)
- Document breaking changes in the release changelog, as well as significant internal infra upgrades
- Connectors: Latest major version of a product; we will be revisiting in Q2/Q3 for supporting multi-major-versions (e.g., we support both Neo4j 3 + Neo4j 4)
- Manual support: 2yr old version for enterprise, 1yr old for cloud
We should have an explicit EOL policy guide and, potentially, an explicit support matrix. We can then move version numbers out of other docs.
Currently available:
Software reqs, including supporting minimums: https://github.com/graphistry/graphistry-cli/blob/master/hardware-software.md
Support, including links to changelogs & versioning: https://www.graphistry.com/support
Graphistry EOL policy is:
-- Avoid most deprecations by making new APIs additive vs. breaking
-- Aim for 1+ year notification window when unavoidable
-- Ex: We still support our 1.0 REST protocol, and are only now moving to officially deprecate it