Skip to main content

​
Overview

VillageSQL follows clear versioning and compatibility policies to help you make informed decisions about deployment and upgrades.

​
VillageSQL Versioning

VillageSQL uses Semantic Versioning (SemVer) to communicate the nature and impact of changes in each release.

​
Version Format

Versions follow the format: MAJOR.MINOR.PATCH

​
Version Increment Rules

  • MAJOR version (e.g., 1.0.0 → 2.0.0): Breaking changes that may require code modifications or database migrations
  • MINOR version (e.g., 0.1.0 → 0.2.0): New features and functionality added in a backwards-compatible manner
  • PATCH version (e.g., 0.0.1 → 0.0.2): Backwards-compatible bug fixes and minor improvements
VillageSQL is currently in pre-1.0 development (version 0.x.x). During this phase, API and extension interfaces may change more frequently as we stabilize the platform.

​
Development Builds

Versions with a pre-release suffix (e.g., 0.0.5-dev) are development builds. The server blocks upgrades from a database initialized with a development build by default. Dev builds are not tested for upgrade compatibility and may include breaking schema or protocol changes. To permit this, start the server with --villagesql-allow-unsafe-dev-upgrade:
Without the flag, the server exits with an error if it detects a dev-version database:
With the flag, the server logs a warning and proceeds:
The server exits with an error if the flag is specified but the current version is not a development build:
Or if no schema upgrade is being performed:

​
Extension Compatibility

VillageSQL extensions are version-specific. An extension built for one version of VillageSQL may not work with another version. When upgrading VillageSQL:
  1. Check extension compatibility for the new version
  2. Update or rebuild extensions as needed
  3. Test extensions in a development environment before production deployment
See the Upgrade Guide for detailed upgrade procedures.