New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extension version maintenance #3353
Comments
I looked into DuckDB a bit. They install extensions to When the user tries to load a extension, the released DuckDB binary looks for the extension based on |
I think we do need to keep track of the version of locally-installed extensions. Instead of installing to But I am not sure whether we should make the extension version the same as kuzu version or use the current approach of having a separate version string. The advantage of our current approach is that for minor releases, the users may not need to reinstall the extensions. |
For extensions released for internal testings, let's make a rule of having a |
Added extension version to local path in #3354 |
I checked duckdb, they don't have repo to host extensions for dev build. |
I think this would be pretty hard. I don't think there is a mechanism that allows us to check the library version before actually loading the lib. @mewim Do you have any ideas on check the version of lib? |
After changing path to |
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:
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.${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.
The text was updated successfully, but these errors were encountered: