Extensions
Extension Versioning
Most software has some sort of version number. Version numbers serve a few important goals:  
* Tie a binary to a specific state of the source code
* Allow determining the expected feature set
* Allow determining the state of the APIs
* Allow efficient processing of bug reports (e.g., bug `#1337` was introduced in version `v3.4.5` )
* Allow determining chronological order of releases (e.g., version `v1.2.3` is older than `v1.2.4`)
* Give an indication of expected stability (e.g., `v0.0.1` is likely not very stable, whereas `v13.11.0` probably is stable)  
Just like [DuckDB itself](#docs:dev:release_calendar), DuckDB extensions have their own version number. To ensure consistent semantics
of these version numbers across the various extensions, DuckDB's [Core Extensions](#docs:extensions:core_extensions) use
a versioning scheme that prescribes how extensions should be versioned. The versioning scheme for Core Extensions is made up of 3 different stability levels: **unstable**, **pre-release**, and **stable**.
Let's go over each of the 3 levels and describe their format:  
#### Unstable Extensions {#docs:extensions:versioning_of_extensions::unstable-extensions}  
Unstable extensions are extensions that can't (or don't want to) give any guarantees regarding their current stability,
or their goals of becoming stable. Unstable extensions are tagged with the **short git hash** of the extension.  
For example, at the time of writing this, the version of the `vss` extension is an unstable extension of version `690bfc5`.  
What to expect from an extension that has a version number in the **unstable** format?  
* The state of the source code of the extension can be found by looking up the hash in the extension repository
* Functionality may change or be removed completely with every release
* This extension's API could change with every release
* This extension may not follow a structured release cycle, new (breaking) versions can be pushed at any time  
#### Pre-Release Extensions {#docs:extensions:versioning_of_extensions::pre-release-extensions}  
Pre-release extensions are the next step up from Unstable extensions. They are tagged with version in the **[SemVer](https://semver.org/)** format, more specifically, those in the `v0.y.z` format.
In semantic versioning, versions starting with `v0` have a special meaning: they indicate that the more strict semantics of regular (` >v1.0.0`) versions do not yet apply. It basically means that an extensions is working
towards becoming a stable extension, but is not quite there yet.  
For example, at the time of writing this, the version of the `delta` extension is a pre-release extension of version `v0.1.0`.  
What to expect from an extension that has a version number in the **pre-release** format?  
* The extension is compiled from the source code corresponding to the tag.
* Semantic Versioning semantics apply. See the [Semantic Versioning](https://semver.org/) specification for details.
* The extension follows a release cycle where new features are tested in nightly builds before being grouped into a release and pushed to the `core` repository.
* Release notes describing what has been added each release should be available to make it easy to understand the difference between versions.  
#### Stable Extensions {#docs:extensions:versioning_of_extensions::stable-extensions}  
Stable extensions are the final step of extension stability. This is denoted by using a **stable SemVer** of format `vx.y.z` where `x>0`.  
For example, at the time of writing this, the version of the `parquet` extension is a stable extension of version `v1.0.0`.  
What to expect from an extension that has a version number in the **stable** format? Essentially the same as pre-release extensions, but now the more
strict SemVer semantics apply: the API of the extension should now be stable and will only change in backwards incompatible ways when the major version is bumped.
See the SemVer specification for details