kuzu
kuzu copied to clipboard
Extension version maintenance
We need to think through how we will maintain extension versions and require users to reinstall them as they bump up or down their Kuzu versions. Specifically we need to make the following decisions:
- Extension version releases: We release our official extensions here: https://extension.kuzudb.com/. However, this repo contains some extension releases that are purely for testing purposes. Although users do not need to know about this repo or care, I think this does not look good.
- The extension version the binaries know about: When building from source, our CMakeLists.txt file contains a single line for the versions of the extensions to look:
add_definitions(-DKUZU_EXTENSION_VERSION="0.2.6")
. So our binary knows about a single "global extension version". An alternative to this could be to have "extension-specific-versions". That is we have different extension versions for different extensions. For example, httpfs could require v 0.1.0 while postgres scanner could require v 0.2.6. Both options have pros and cons. A single global extension version means that as users change their Kuzu version, they would be forced to reinstall every extension, which may be OK, even if the previous extension binary they had is the same binary. This also means that we rebuild and re-release every extension binary in each of our non-minor releases. Extension-specific-version would only require users to reinstall an extension only if it's strictly necessary and the previous extension version will not work with the new Kuzu version. - Mechanism to actually validate that the right extension version is installed: More importantly, we currently do not have any mechanism to check if an extension version is valid or not for the running Kuzu version. The -DKUZU_EXTENSION_VERSION flag seems only to be used when installing an extension and not for when checking if an extension already exists. This I say because it looks like there is a single directory
${xyz}/extension
under which we store all the extension binaries. So the directory into which we store extensions do not have version numbers in the directory name. Further the extension binaries do not have version numbers on them (e.g., regardless of the extension version number, all https extension binaries have the namelibhttpfs.kuzu_extension
. So we'll get unclear error messages likesymbol not found
when blindly dynamically linking against these. Chang tested this and can expand on this.
We need to make decisions on these points. We should do our research and look into what other systems are doing and try to make a more informed decision.