This page describes Stardog’s compatibility policy.
The Stardog 7.x release (“Stardog” for short) is a major milestone in the development of the system. Stardog is a stable platform for the growth of projects and programs written for Stardog.
Stardog provides (and defines) several user-visible things:
It is intended that programs, as well as SPARQL queries, written to Stardog APIs, protocols, and interfaces will continue to run correctly, unchanged, over the lifetime of Stardog. That is, over all releases identified by version
7.x.y. At some indefinite point, Stardog 8.x will be released; but, until that time, and likely even after it, Stardog programs that work today should continue to work even as future releases of Stardog occur. APIs, protocols, and interfaces may grow, acquiring new parts and features, but not in a way that breaks existing Stardog programs.
Although we expect that nearly all Stardog programs will maintain this compatibility over time, it is impossible to guarantee that no future change will break any program. This document sets expectations for the compatibility of Stardog programs in the future. The main, foreseeable reasons for which this compatibility may be broken in the future include:
- Security: We reserve the right to break compatibility if doing so is required to address a security problem in Stardog.
- Unspecified behavior: Programs that depend on unspecified behaviors may not work in the future if those behaviors are modified.
- 3rd Party Specification Errors: It may become necessary to break compatibility of Stardog programs in order to address problems in some 3rd party specification.
- Bugs: It will not always be possible to fix bugs found in Stardog–or in its 3rd party dependencies–while also preserving compatibility. With that proviso, we will endeavor to only break compatibility when repairing critical bugs.
The relevant specs include the Stardog-specific specifications documented on this site, but also W3C (and other) specifications of various languages, including SPARQL, RDF, RDFS, OWL 2, HTTP, Google Protocol Buffers, as well as others.
It is always possible that the performance of a Stardog program may be (adversely) affected by changes in the implementation of Stardog. No guarantee can be made about the performance of a given program between releases, except to say that our expectation is that performance will generally trend in the appropriate direction.
We expect that data safety will always be given greater weight than any other consideration. But since Stardog stores a user’s data differently from the form in which data is input to Stardog, we may from time to time change the way it is stored such that explicit data migration will be necessary.
Stardog provides for two data migration strategies:
- Command-line migration tool(s)
- Dump and reload
We expect that explicit migrations may be required from time to time between different releases of Stardog. We will endeavor to minimize the need for such migrations. We will only require the “dump and reload” strategy between major releases of Stardog (that is, from 1.x to 2.x, etc.), unless that strategy of migration is required to repair a security or other data safety bug.