apunkt/sqlite-vec
1
0
Fork 0
mirror of https://github.com/asg017/sqlite-vec.git synced 2026-04-25 00:36:56 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

Remove vec_npy_each from default entrypoint and move to sqlite3_vec_numpy_init entrypoint

Browse source
This commit is contained in:
Alex Garcia 2024-09-25 23:07:17 -07:00
parent 70dce09747
commit 763aad5d6a
6 changed files with 92 additions and 187 deletions
Download patch file Download diff file Expand all files Collapse all files

53
site/versioning.md
View file

@ -4,51 +4,16 @@
[Semantic Versioning](https://semver.org/), so "minor" release like "0.2.0" or
"0.3.0" may contain breaking changes.
But what exactly counts as a "breaking change" in a SQLite extension? The line
isn't so clear, unforetunately. Here are a all the surfaces that COULD count as
a "breaking change":
Only SQL functions, table functions, and virtual tables that are defined in the default `sqlite3_vec_init` entrypoint are considered as the `sqlite-vec` API for semantic versioning. This means that other entrypoints and other SQL functions should be considered unstable, untested, and possibly dangerous.
- SQL functions and columns on virtual tables
- The C API (extension entrypoints)
- "Bindings" like the official `pip` and `npm` packages
- Release assets like the pre-compile extensions
For the SQL API, a "breaking change" would include:
## What counts as a "breaking change"?
- Removing a function or module
- Changing the number or types of arguments for an SQL function
- Changing the require arguments of position of a table functions
- Changing the `CREATE VIRTUAL TABLE` constructor of a virtual table in a backwards-incompatible way
- Removing columns from a virtual table or table function
### Changes to SQL functions
- Re-naming or removing an SQL function
- Changing the number of required SQL parameters
### Changes to SQL virtual tables
- The number of
### Changes to the C API
Currently there is no "official" C API for `sqlite-vec`. However, there are
entrypoints defined in C that C developers or developers using FFI can call. Any changes to these entrypoints would be a breaking change.
### Compile-time options
The removal of any compile time options
## When is `v1.0` coming?
In a few months! The main problems I want to solve before `v1.0` include:
- Metadata columns
- Metadata filtering
- ANN indexing
- Quantization + pre-transformations
Once those items are complete, I will likely create a `v1.0` release, along with
renaming the `vec0` virtual table modile to `vec1`. And if future major releases
are required, a `v2.0` major releases will be made with new `vec2` virtual
tables and so on.
Ideally, only a `v1` major release would be required. But who knows what the
future has in store with vector search!
In general, I will try my best to maximize stability and limit the number of
breaking changes for future `sqlite-vec` versions.
The official "bindings" to `sqlite-vec`, including the Python/Node.js/Ruby/Go/Rust are subject to change and are not covered by semantic versioning.
Though I have no plans to change or break them, and would include notes in changelogs if that ever needs to happen.