Update documentation to use dynamic versioning

[mewim]

No description provided.

[Copilot]

Pull Request Overview

This PR introduces dynamic versioning in the documentation by centralizing the version value in a JSON file and automating its updates.

• Added src/version.json to store the current version.
• Updated MDX docs (installation.mdx, get-started/index.mdx, client-apis/c.mdx) to import version and replace static snippets with <Code> components driven by dynamic code blocks.
• Added scripts/update-version.cjs and an NPM script to fetch the latest GitHub release and update version.json; removed the old GitHub Actions workflow.

Reviewed Changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/version.json	Introduce a new JSON file to hold the version value.
src/content/docs/installation.mdx	Import version.json, define DOWNLOAD_LINKS, and swap out hard-coded snippets for <Code> components.
src/content/docs/get-started/index.mdx	Import version.json, define CODE_BLOCKS, and replace static Java/Swift snippets with <Code>.
src/content/docs/client-apis/c.mdx	Import version.json, define CMAKE_CONTENT, and use <Code> in place of static CMake example.
scripts/update-version.cjs	New script to fetch latest GitHub release and write version.json.
package.json	Add update-version to the scripts section.
.github/workflows/update-kuzu-version.yml	Removed obsolete workflow in favor of the update script.

Comments suppressed due to low confidence (4)

scripts/update-version.cjs:13

• The log message refers to LatestVersion.json but the file being written is version.json. Update the message to Updating version.json... for clarity and consistency.

    console.log("Updating LatestVersion.json...");

scripts/update-version.cjs:1

• There are no tests for the version update script. Consider adding unit or integration tests (e.g., mocking the GitHub API response and verifying version.json is updated correctly) to catch regressions.

const GITHUB_API_URL = "https://api.github.com/repos/kuzudb/kuzu/releases/latest";

scripts/update-version.cjs:7

• Ensure fetch is available in the target Node environment (Node v18+ or via a polyfill like node-fetch); otherwise import or require it explicitly to avoid runtime errors.

    const response = await fetch(GITHUB_API_URL);

src/content/docs/client-apis/c.mdx:9

• The CMake snippet no longer includes a URL_HASH for the download. Re-adding a SHA256 hash in ExternalProject_Add helps verify the integrity of the archive and prevents tampering.

export const CMAKE_CONTENT =`cmake_minimum_required(VERSION 3.11)

[sdht0]

Nice work. I like it, except for the bad indentation in the code blocks.

[sdht0]

We should have a way to manually specify the version, as this script should be run as part of the dev to main release merge, which could be before the actual version has been released.

[mewim]

I have changed the behavior:

• For the deployment pipeline, there is a way to skip version updating, so that the build process uses the version specified in JSON directly.
• For dev docker deployment, always use the manually specified version (not doing auto version update).

Since now it is just a JSON file that can easily be edited directly. Using the script or workflow to do version update is mainly for automatically version maintaining but not necessary.

[sdht0]

Thinking some more, instead of auto updating on deploy, how about we just check for changes and fail the build. This way, there won't ever me a mismatch between what we see locally on npm run dev vs what is actually deployed.

[mewim]

I personally do not mind too much about the mismatching. I would prefer to just keep the JSON as a placeholder and allow the script to automatically do it. For https://github.com/kuzudb/kuzudb.github.io I do not update LatestVersion.json at all and solely rely on the script to maintain it during the deployment.

[sdht0]

Although auto check won't really work for a new release.

I don't really like the magical version rewrite during deploy. I think the better way is to add a commit with the new version, like the auto format CI job.

[mewim]

I think it will work for new release though. We usually build the binaries first and then push the docs. Anyway, feel free to change the behavior to allow manual triggering or committing to the branch. I just personally do not care about it.