or run

npx @tessl/cli init
Log in

Version

Tile

Overview

Evals

Files

docs

cli-interface.mdconfiguration.mdindex.mdrelease-types.mdversion-bumping.md
tile.json

release-types.mddocs/

Release Types

Semantic versioning system with extended release types, validation utilities, and conventional commit support for flexible version management strategies.

Capabilities

Release Type Definition

Extended semantic versioning type system supporting standard semver types plus custom release strategies.

/**
 * Extended release type supporting semver types plus custom strategies
 */
type ReleaseType = 
  | "major" | "minor" | "patch"                    // Standard releases
  | "premajor" | "preminor" | "prepatch" | "prerelease"  // Prerelease types
  | "next" | "conventional";                       // Extended strategies

Note: The utility functions and arrays for release type validation (isReleaseType, isPrerelease, releaseTypes, prereleaseTypes) are internal implementation details and not exported from the main bumpp package. For external validation, you can implement your own type checking or work directly with the string values.

Usage Examples:

import { versionBump, type ReleaseType } from "bumpp";

// Direct string validation for release types
const validReleaseTypes = [
  "major", "minor", "patch",
  "premajor", "preminor", "prepatch", "prerelease",
  "next", "conventional"
] as const;

function isValidReleaseType(value: string): value is ReleaseType {
  return validReleaseTypes.includes(value as ReleaseType);
}

// Usage
function handleRelease(input: string) {
  if (isValidReleaseType(input)) {
    return versionBump(input);
  }
  throw new Error(`Invalid release type: ${input}`);
}

Standard Semantic Versioning

Major Version Bumps

Breaking changes that are not backward compatible.

// 1.2.3 → 2.0.0
await versionBump("major");

Use Cases:

  • Breaking API changes
  • Removed functionality
  • Major architecture changes
  • Non-backward compatible updates

Minor Version Bumps

New features that are backward compatible.

// 1.2.3 → 1.3.0
await versionBump("minor");

Use Cases:

  • New features added
  • New API endpoints
  • Enhanced functionality
  • Backward compatible improvements

Patch Version Bumps

Bug fixes that are backward compatible.

// 1.2.3 → 1.2.4
await versionBump("patch");

Use Cases:

  • Bug fixes
  • Security patches
  • Performance improvements
  • Documentation updates

Prerelease Versioning

Premajor Releases

Prerelease version for upcoming major release.

// 1.2.3 → 2.0.0-0
await versionBump("premajor");

// With custom preid
await versionBump({
  release: "premajor",
  preid: "alpha"  // → 2.0.0-alpha.0
});

Preminor Releases

Prerelease version for upcoming minor release.

// 1.2.3 → 1.3.0-0
await versionBump("preminor");

// With custom preid
await versionBump({
  release: "preminor", 
  preid: "beta"  // → 1.3.0-beta.0
});

Prepatch Releases

Prerelease version for upcoming patch release.

// 1.2.3 → 1.2.4-0  
await versionBump("prepatch");

// With custom preid
await versionBump({
  release: "prepatch",
  preid: "rc"  // → 1.2.4-rc.0
});

Prerelease Increments

Increment existing prerelease version.

// 1.2.4-0 → 1.2.4-1
// 1.2.4-alpha.0 → 1.2.4-alpha.1
await versionBump("prerelease");

Extended Release Strategies

Next Release Strategy

Intelligent prerelease bumping that uses the current version's prerelease identifier.

// Uses existing preid if available
await versionBump("next");

// Examples:
// 1.2.3 → 1.2.4-0 (creates new prerelease)
// 1.2.4-alpha.0 → 1.2.4-alpha.1 (increments existing)
// 1.2.4-beta.2 → 1.2.4-beta.3 (maintains preid)

Next Strategy Logic:

  1. If current version has prerelease suffix → increment prerelease
  2. If current version is stable → create new prerelease with default preid
  3. Maintains consistency with existing prerelease naming

Conventional Commits Strategy

Automatically determines version bump based on conventional commit messages since last release.

// Analyzes recent commits to determine bump type
await versionBump("conventional");

Conventional Commit Analysis:

  • fix: commits → patch bump
  • feat: commits → minor bump
  • BREAKING CHANGE: or ! → major bump
  • Other commits → patch bump

Usage Examples:

# Recent commits:
# fix: resolve memory leak in parser
# feat: add new export format
# docs: update README

# Results in minor bump due to feat: commit

Prerelease Identifiers

Default Prerelease ID

Default prerelease identifier when none is specified.

// Uses "beta" as default preid
await versionBump("prerelease");  // → 1.2.4-beta.0

Custom Prerelease IDs

Specify custom prerelease identifiers for different release channels.

// Alpha releases
await versionBump({
  release: "prerelease",
  preid: "alpha"     // → 1.2.4-alpha.0
});

// Beta releases  
await versionBump({
  release: "prepatch",
  preid: "beta"      // → 1.2.4-beta.0
});

// Release candidates
await versionBump({
  release: "preminor", 
  preid: "rc"        // → 1.3.0-rc.0
});

// Custom identifiers
await versionBump({
  release: "premajor",
  preid: "dev"       // → 2.0.0-dev.0
});

Version Validation

Runtime Type Checking

Implement custom validation for release types in your application.

import { versionBump, type ReleaseType } from "bumpp";

const releaseTypes = [
  "major", "minor", "patch",
  "premajor", "preminor", "prepatch", "prerelease",
  "next", "conventional"
] as const;

const prereleaseTypes = [
  "premajor", "preminor", "prepatch", "prerelease"
] as const;

function validateReleaseInput(input: unknown): ReleaseType {
  if (typeof input !== "string") {
    throw new Error("Release type must be a string");
  }
  
  if (!releaseTypes.includes(input as ReleaseType)) {
    throw new Error(`Invalid release type: ${input}`);
  }
  
  return input as ReleaseType;
}

// Usage
try {
  const releaseType = validateReleaseInput(userInput);
  await versionBump(releaseType);
} catch (error) {
  console.error("Invalid input:", error.message);
}

Prerelease Detection

Check if a release type will create a prerelease version.

function isPrerelease(releaseType: ReleaseType): boolean {
  return prereleaseTypes.includes(releaseType as any);
}

function planRelease(releaseType: ReleaseType) {
  if (isPrerelease(releaseType)) {
    console.log("This will create a prerelease version");
    console.log("Remember to set appropriate preid if needed");
  } else {
    console.log("This will create a stable release");
  }
  
  return versionBump(releaseType);
}

Release Type Workflows

Development Workflow

Typical development release workflow using different release types.

// Development cycle
await versionBump("prepatch");   // 1.2.3 → 1.2.4-beta.0
await versionBump("prerelease"); // 1.2.4-beta.0 → 1.2.4-beta.1
await versionBump("prerelease"); // 1.2.4-beta.1 → 1.2.4-beta.2

// Release candidate
await versionBump({
  release: "prerelease",
  preid: "rc"                    // 1.2.4-beta.2 → 1.2.4-rc.0
});

// Final release
await versionBump("patch");      // 1.2.4-rc.0 → 1.2.4

Feature Branch Workflow

Using prerelease versions for feature branches.

// Feature branch prereleases
await versionBump({
  release: "preminor",
  preid: "feature-auth"          // 1.2.3 → 1.3.0-feature-auth.0
});

// Continue development
await versionBump("prerelease"); // 1.3.0-feature-auth.0 → 1.3.0-feature-auth.1

// Merge to main and release
await versionBump("minor");      // 1.3.0-feature-auth.1 → 1.3.0

CI/CD Integration

Automated release type selection in CI/CD pipelines.

// Environment-based release strategy
const releaseType = process.env.BRANCH_NAME === "main" 
  ? "conventional"     // Use conventional commits on main
  : "prerelease";      // Use prerelease for other branches

await versionBump({
  release: releaseType,
  preid: process.env.BRANCH_NAME === "develop" ? "beta" : "alpha"
});