mirror of
https://github.com/asg017/sqlite-vec.git
synced 2026-04-25 00:36:56 +02:00
docs
This commit is contained in:
parent
4febdff11a
commit
356f75cca7
17 changed files with 350 additions and 166 deletions
|
|
@ -1,10 +1,12 @@
|
|||
# Semantic Versioning for `sqlite-vec`
|
||||
|
||||
`sqlite-vec` is pre-v1, so according to the rules of [Semantic Versioning](https://semver.org/),
|
||||
so "minor" release like "0.2.0" or "0.3.0" may contain breaking changes.
|
||||
`sqlite-vec` is pre-v1, so according to the rules of
|
||||
[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":
|
||||
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":
|
||||
|
||||
- SQL functions and columns on virtual tables
|
||||
- The C API (extension entrypoints)
|
||||
|
|
@ -13,7 +15,6 @@ Here are a all the surfaces that COULD count as a "breaking change":
|
|||
|
||||
## What counts as a "breaking change"?
|
||||
|
||||
|
||||
### Changes to SQL functions
|
||||
|
||||
- Re-naming or removing an SQL function
|
||||
|
|
@ -25,14 +26,13 @@ Here are a all the surfaces that COULD count as a "breaking change":
|
|||
|
||||
### 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
|
||||
|
||||
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
|
||||
|
||||
### 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:
|
||||
|
|
@ -42,8 +42,13 @@ In a few months! The main problems I want to solve before `v1.0` include:
|
|||
- 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.
|
||||
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!
|
||||
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.
|
||||
In general, I will try my best to maximize stability and limit the number of
|
||||
breaking changes for future `sqlite-vec` versions.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue