Release Process

January 8, 2026 · View on GitHub

This document describes the complete release process for the Minecraft Bedrock Language Server monorepo.

Overview

The repository uses Release Drafter for release notes. The process is automated with minimal manual intervention required.

Package Structure

This repository contains multiple packages that can be versioned and released independently:

Core Bedrock packages:

bc-minecraft-bedrock-types - Core type definitions
bc-minecraft-bedrock-vanilla-data - Vanilla data structures
bc-minecraft-bedrock-command - Command parsing and handling
bc-minecraft-molang - Molang expression support
bc-minecraft-bedrock-project - Project management
bc-minecraft-bedrock-diagnoser - Diagnostic tools

IDE/LSP packages:

@blockception/ide-shared - Shared IDE utilities
bc-minecraft-lsp-client - LSP client implementation
bc-minecraft-lsp - Language server implementation (depends on all Bedrock packages above)
blockceptionvscodeminecraftbedrockdevelopmentextension - VS Code extension

Independent packages:

bc-minecraft-bedrock-shared - Independent shared utilities
bc-minecraft-project - Base project utilities
vanilla-scraper - Data extraction tool
generate-command-data - Command data generator

Process Flow

Developer PR → Main Branch → Version Update (Auto/Manual) → Release Draft → Published Release
     ↓            ↓              ↓                            ↓              ↓
  Changes      Automated      Automated Workflow         Maintainer     Auto-publish
  Merged    Release Draft    Creates Version PR          Creates        to NPM &
            Created          (Release creates tags)       Release        Marketplace

Step-by-Step Process

1. Developer Makes Changes

When a developer makes changes:

# Make your code changes
git checkout -b fix/some-bug

# Make changes to the code

# Commit everything
git add .
git commit -m "fix: description of the fix"
git push origin fix/some-bug

Create a pull request with your changes.

2. PR is Merged to Main

When the PR is merged to main, the Release Drafter workflow runs:

Release Drafter Workflow

What it does: Creates or updates a release draft in GitHub Releases
Draft contents:
- Aggregated changelog entries
- Categorized changes (features, fixes, etc.)
- Version number based on labels
File: .github/workflows/release-drafter.yaml

3. Version Update

When ready to release, maintainers update package versions. This can be done automatically or manually:

Option A: Automated Version Bump (Recommended)

Use the NPM Version Bump workflow (.github/workflows/npm-version-bump.yaml):

Go to Actions → 📦 NPM Version Bump
Click Run workflow
Select the version bump type:
- patch - Bug fixes and minor changes (0.0.X)
- minor - New features, backwards compatible (0.X.0)
- major - Breaking changes (X.0.0)
- prepatch - Pre-release patch (0.0.X-0)
- preminor - Pre-release minor (0.X.0-0)
- premajor - Pre-release major (X.0.0-0)
The workflow will automatically:
- Update all package.json files in packages and VSCode IDE
- Create a Pull Request with the version changes
After merging the PR:
- Create a GitHub Release to automatically generate git tags

Option B: Manual Version Update

Manually update package versions if you need more control:

What to update:

✅ Version numbers in package.json files for affected packages
✅ CHANGELOG entries for each package
✅ Internal dependencies to match new versions

Best practices:

Follow semantic versioning (major.minor.patch)
Update all interdependent packages together
Keep the LSP and extension versions synchronized

4. Create and Publish Release

Maintainer action required:

Go to GitHub Releases
Find the latest draft release
Review the release notes
Edit if necessary
Click "Publish release"

When release is published:

Release Pipeline workflow is triggered (.github/workflows/release-pipeline.yaml)
VSCode extension is automatically published to marketplace
NPM packages can be published (may require additional workflow setup)