You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In January 2021 (mid 3.10 development), Sergey Fodoseev and I raised the compile time (and runtime) SQLite version requirements for the sqlite3 standard library extension module to SQLite 3.7.15 (2012-12-12) or newer (commit cf0b239). That enabled us to clean up the code by getting rid of a lot of preprocessor conditionals and other version specific workarounds.
For Python 3.13 (to be released October 2024), I'll raise the version requirements to either SQLite 3.8.11.1 (2015-07-29), 3.14.2 (2016-09-12), or 3.15.2 (2016-11-28). Preferably the latter.
AFAICS on DistroWatch, we should be fine with any of those SQLite versions, for all major distros1.
Major clean-ups:
For SQlite 3.8.11.1, I can remove a lot of conditional code related to CTEs and deterministic functions.
For SQLite 3.14.2 I no longer need to implement two different variants of the trace callback.
For SQLite 3.15.2, I can remove special handling for legacy deterministic user function behaviour.
(Also posted on Discord.)
In January 2021 (mid 3.10 development), Sergey Fodoseev and I raised the compile time (and runtime) SQLite version requirements for the sqlite3 standard library extension module to SQLite 3.7.15 (2012-12-12) or newer (commit cf0b239). That enabled us to clean up the code by getting rid of a lot of preprocessor conditionals and other version specific workarounds.
For Python 3.13 (to be released October 2024), I'll raise the version requirements to either SQLite 3.8.11.1 (2015-07-29), 3.14.2 (2016-09-12), or 3.15.2 (2016-11-28). Preferably the latter.
AFAICS on DistroWatch, we should be fine with any of those SQLite versions, for all major distros1.
Major clean-ups:
Linked PRs
Footnotes
RHEL-7.9 ships with SQLite 3.7.17 but is EOL in June 2024. ↩