3 ms·

If you read through their docs [0] you'd see they're committed to maintaining backwards compatibility with all SQLite 3 releases. There haven't been breaking ch

If you read through their docs [0] you'd see they're committed to maintaining backwards compatibility with all SQLite 3 releases. There haven't been breaking changes since 2004. In addition, the library is incredibly easy to embed with any project as it's largely a self-contained system [1]. If SQLite 4 were released with breaking changes, you could happily continue using SQLite 3. [0] https://sqlite.org/onefile.html https://sqlite.org/onefile.html [1] https://sqlite.org/selfcontained.html https://sqlite.org/selfcontained.html

upofadown 9y ago
This is a document format we are talking about here that should be good for the ages, not just 13 years. In practice you would have to define your document format in terms of a particular version of SQLite. So you would have to unambiguously document that version in such detail that you cover everything that anyone would ever want and be able to do. Once that version of SQLite becomes unmaintained then things are broken. Someone would have to maintain that version of what would now be the ODF SQL disk format forever. Much of what would have to be maintained would be pointless complexity not required for the representation of documents.
- SQLite 9y ago
  You seem to be operating under the assumption that the SQLite database file format is an ad-hoc, dodgy affair that the maintainers might change on a whim. I'd like to try to dispel that notion. The SQLite database file format has been unchanged (except by adding extensions through well-defined mechanisms) since 2004. And we developers have pledged to continue that 100% compatibility through at least the year 2050. The file format is cross-platform and byte-order independent. We have an extensive test suite to help us guarantee that each new version of SQLite is completely file compatible with all those that came before. The file format is documented (https://sqlite.org/fileformat.html https://sqlite.org/fileformat.html) to sufficient detail that the spec alone can and has been used to create a compatible reader/writer. (I know this because the authors of the compatible reader/writer software pointed out deficiencies in the spec which I subsequently corrected.) The file format is relatively simple. A reader for SQLite could be written from the spec with no more effort than it would take to implement a ZIP archive reader with its decompressor from spec. There is approximately 1 trillion (10^12) SQLite database files in active use today. Even without the promises from developers, the huge volume of legacy database files suggests that the SQLite database file format will be around for a long time yet. The latest version of SQLite will happily read and write any SQLite3 database written since the file format was designed in 2004. Ancient legacy versions of the SQLite library will read and write databases created yesterday, as long as those databases do not use any of the extensions that were added later.
- randyrand 9y ago
  As long as SQLite4 includes built in SQLite3 migration/loading, breaking changes are not as bad.

upofadown 9y ago

This is a document format we are talking about here that should be good for the ages, not just 13 years. In practice you would have to define your document format in terms of a particular version of SQLite. So you would have to unambiguously document that version in such detail that you cover everything that anyone would ever want and be able to do. Once that version of SQLite becomes unmaintained then things are broken. Someone would have to maintain that version of what would now be the ODF SQL disk format forever. Much of what would have to be maintained would be pointless complexity not required for the representation of documents.

SQLite 9y ago
You seem to be operating under the assumption that the SQLite database file format is an ad-hoc, dodgy affair that the maintainers might change on a whim. I'd like to try to dispel that notion. The SQLite database file format has been unchanged (except by adding extensions through well-defined mechanisms) since 2004. And we developers have pledged to continue that 100% compatibility through at least the year 2050. The file format is cross-platform and byte-order independent. We have an extensive test suite to help us guarantee that each new version of SQLite is completely file compatible with all those that came before. The file format is documented (https://sqlite.org/fileformat.html https://sqlite.org/fileformat.html) to sufficient detail that the spec alone can and has been used to create a compatible reader/writer. (I know this because the authors of the compatible reader/writer software pointed out deficiencies in the spec which I subsequently corrected.) The file format is relatively simple. A reader for SQLite could be written from the spec with no more effort than it would take to implement a ZIP archive reader with its decompressor from spec. There is approximately 1 trillion (10^12) SQLite database files in active use today. Even without the promises from developers, the huge volume of legacy database files suggests that the SQLite database file format will be around for a long time yet. The latest version of SQLite will happily read and write any SQLite3 database written since the file format was designed in 2004. Ancient legacy versions of the SQLite library will read and write databases created yesterday, as long as those databases do not use any of the extensions that were added later.
randyrand 9y ago
As long as SQLite4 includes built in SQLite3 migration/loading, breaking changes are not as bad.