Changelog

KB Labs is a monorepo of ~125 packages across 18 sub-repositories. Release notes exist at two levels: per-package changelogs maintained by the Release Manager, and a workspace-level changelog that aggregates notable changes across a release cycle.

Current version

KB Labs is currently in pre-release (0.x). The platform is stable enough for active development but the public API is not yet frozen — breaking changes are possible with minor version bumps until 1.0.0.

Where to find changelogs

Workspace-level changelog

The aggregated changelog lives at:

.kb/release/CHANGELOG.md

It's maintained by the Release Manager plugin and updated on each release cycle. It lists which packages were bumped, to which version, and any functional changes noted in the release plan.

Per-package changelogs

Each sub-repository maintains its own release plans and history under:

.kb/release/plans/<package-name>/current/plan.json
.kb/release/history/<package-name>/

Git history

The most granular source of truth is git history in each sub-repository. Since sub-repos stay on main and workspace commits represent verified snapshots, the workspace commit history reflects stable states:

# Workspace-level history (each commit = verified snapshot)
git log --oneline
 
# Sub-repo history
cd platform/kb-labs-cli
git log --oneline

How releases work

KB Labs uses a unified release pipeline managed by the @kb-labs/release-manager plugin:

1. Plan — each package gets a release plan with version bump type (patch/minor/major) and change summary
2. Build — all packages built in dependency order
3. Pack — pnpm pack to verify the artifact before publish
4. Publish — packages published to npm (private registry during pre-release)
5. Workspace commit — workspace submodule pointers updated and committed as a stable snapshot

Release cycle is managed per package group. Related packages bump together to maintain compatibility.

Version policy

KB Labs packages follow semantic versioning:

During the 0.x phase, the platform aims for backward compatibility within minor versions but doesn't guarantee it. Check release plans and git history when upgrading.

Package groups

Packages are released in coordinated groups to avoid version skew:

When upgrading, bump the entire group together. Mixing versions within a group can cause type errors or runtime mismatches.

Checking for updates

# Check current installed versions
pnpm kb marketplace plugins list
 
# Check for outdated packages
pnpm outdated --filter "@kb-labs/*"
 
# Update a specific package
pnpm kb marketplace update @kb-labs/sdk

Public changelog (coming soon)

A human-friendly public changelog will be published at launch alongside the 1.0.0 release. It will cover:

• Breaking changes with migration guides
• New features by release
• Deprecation notices with timelines

Until then, the .kb/release/CHANGELOG.md file and git history are the authoritative sources.