This file describes the step-by-step process to keep the BLite documentation up to date across all three repositories after a release or feature change.
| Repository | Content | Key files |
|---|---|---|
BLite |
Core engine README | README.md, CHANGELOG.md |
BLite.Server |
Server README | README.md, CHANGELOG.md |
BLite.Website |
Documentation website (Vue + Vite SSG) | package.json, src/router/index.ts, src/views/docs/, src/views/server-docs/ |
- Read
BLite/CHANGELOG.md(first entry) to get the latest BLite engine version. - Read
BLite.Server/CHANGELOG.md(first entry) to get the latest BLite.Server version. - Read
BLite.Website/package.json→"version"field. - Run
git -C ../BLite tag --list "studio-v*" --sort=-version:refnameand take the first result as the latest Studio version (e.g.studio-v3.8.0→3.8.0). This tag drives the download URLs inApp.vueand the badge inHero.vue. - Compare all four values and note any mismatch.
Where versions appear and must stay in sync:
BLite/README.md— NuGet badge, feature descriptions, version-specific mentions.BLite.Server/README.md— version references, compatibility notes.BLite.Website/package.json—"version"should track the latest BLite release.BLite.Website/src/views/docs/Installation.vue— NuGet install commands, version callouts.BLite.Website/src/views/docs/GettingStarted.vue— version mentions in quickstart.BLite.Website/src/views/server-docs/Overview.vue— server version, engine compatibility.BLite.Website/src/views/server-docs/VersionMatrix.vue— full compatibility table.BLite.Website/src/views/server-docs/ServerInstallation.vue— Docker tags, download links.BLite.Website/src/components/Hero.vue—badgetext in the hero section (version + release summary).BLite.Website/src/App.vue— footer download links title and all 6 download URLs (MSI, Portable, .deb, tar.gz, macOS arm64, macOS x64). The URL pattern ishttps://github.com/EntglDb/BLite/releases/download/studio-vX.Y.Z/BLite.Studio-X.Y.Z-<platform>.<ext>. Use the Studio tag version (step 1.4) asX.Y.Z— it may differ from the engine version if a Studio release was cut independently.
Action: Update all version references to match the latest released versions.
- Open
BLite/CHANGELOG.mdand collect all Features entries since the last documentation update. - Do the same for
BLite.Server/CHANGELOG.md. - For each new feature, determine:
- Does the existing documentation already cover it? → Update the relevant page.
- Is it significant enough to need a new dedicated page? → Go to Step 4.
- Is it a minor improvement? → Mention it in the relevant existing page.
CHANGELOG entries are often terse (e.g., "Add session APIs" or "non-blocking checkpoints"). When a feature's scope, public API surface, or behavior is not obvious from the CHANGELOG alone:
- Follow the commit hash — Each CHANGELOG entry links to a commit. Use
git show <hash> --statto see which files were touched. - Read the relevant source files — Focus on:
- New or changed public types, methods, and properties (look for
publicdeclarations inBLite/src/orBLite.Server/src/). - New Protobuf definitions (
BLite.Proto/) for gRPC-level changes. - New or modified REST endpoints (
BLite.Server/src/BLite.Server/Rest/). - New Blazor pages or components (
BLite.Server/src/BLite.Server/Components/).
- New or changed public types, methods, and properties (look for
- Check tests — Unit/integration tests often show usage examples and edge
cases that must be reflected in the documentation. Look in
BLite/tests/andBLite.Server/tests/. - Check
AGENTS.md— The server repo'sAGENTS.mdis kept in sync with the architecture; cross-reference it for naming, invariants, and design decisions.
Goal: Understand the exact public API and behavior before writing or updating documentation. Never document a feature based solely on the CHANGELOG summary — always verify against the source.
For each documentation page, verify that the content reflects the current codebase.
| Page | What to check |
|---|---|
GettingStarted.vue |
Install commands, minimal example, API surface |
Installation.vue |
NuGet package names, target frameworks, version |
Transactions.vue |
Transaction API (BeginTransaction, SaveChanges, session APIs) |
CRUD.vue |
Insert/Update/Delete/FindById signatures |
Querying.vue |
LINQ operators, index usage, async streaming |
Generators.vue |
Source generator attributes, supported types |
CDC.vue |
Change stream API, event types |
Spatial.vue |
R-Tree API, query syntax |
Architecture.vue |
Engine internals, page layout, WAL protocol |
Converters.vue |
Custom converter and HasConversion APIs |
Benchmarks.vue |
Benchmark numbers, comparison methodology |
DynamicAPI.vue |
BLiteEngine / DynamicCollection API |
BLQL.vue |
BLQL operators, filter syntax, fluent API |
TimeSeries.vue |
TimeSeries page type, retention, append API |
KvStore.vue |
IBLiteKvStore API, TTL, batch, prefix scan |
Comparisons.vue |
Feature matrix vs LiteDB / SQLite |
| Page | What to check |
|---|---|
Overview.vue |
Architecture diagram, endpoint table, feature list |
ServerInstallation.vue |
Docker image, Windows/Linux install, port config |
Protocol.vue |
gRPC services, REST endpoints, auth model, BLQL over REST |
ServerStudio.vue |
Studio screenshots, feature description, auth flow |
Clients.vue |
SDK install commands, feature matrix, code samples |
VersionMatrix.vue |
Engine ↔ Server ↔ Client SDK compatibility table |
| File | What to check |
|---|---|
BLite/README.md |
Feature list, badges, code samples, version, target frameworks |
BLite.Server/README.md |
Architecture diagram, endpoints table, feature list, version |
Action: For each page, read the source code of the relevant feature and compare it against the documentation. Fix any outdated API signatures, removed parameters, renamed types, or missing capabilities.
When a new feature requires a dedicated page:
- Create a new
.vuefile in the appropriate directory:- BLite feature →
src/views/docs/MyFeature.vue - Server feature →
src/views/server-docs/MyFeature.vue
- BLite feature →
- Follow the same structure as existing pages (template with sections, code samples, API reference).
- Open
src/router/index.ts. - Import the new component at the top of the file.
- Add a child route under the
/docsor/serverparent with:path— URL slug (kebab-case).component— the imported component.meta.title— SEO title (include "BLite" and a concise description).meta.description— SEO description (150–160 chars, keyword-rich).
- Open the parent layout component (
Docs.vueorServerDocs.vue). - Add a
<router-link>entry in the sidebar navigation list, in logical order.
- Link to the new page from the relevant existing pages.
- If the feature was mentioned in the README, link to the docs page from there.
Bump the "version" field in BLite.Website/package.json to match the latest
BLite engine version (e.g., "3.8.0"). This keeps the website version aligned
with the engine it documents.
cd BLite.Website
npm run build
npm run preview- Navigate through every documentation page and verify rendering.
- Check that all code samples are syntax-highlighted and accurate.
- Verify that internal links between pages work.
- Spot-check SEO meta tags in the page source.
- Version numbers are consistent across all READMEs and the website
- Studio tag checked (
git tag --list "studio-v*") and download URLs updated accordingly - Hero badge in
Hero.vueupdated with new version and release summary - Footer download links in
App.vueupdated (title + all 6 URLs) - CHANGELOG features are reflected in the documentation
- Existing pages are accurate with the current API
- New pages are created for significant new features
- Routes and sidebar links are added for new pages
-
package.jsonversion is bumped - Website builds without errors
- Version matrix page is up to date