Skip to content

RELEASES.md

Latest commit

 

History

History
101 lines (67 loc) · 2.1 KB

RELEASES.md

File metadata and controls

101 lines (67 loc) · 2.1 KB

Release Policy

This document defines the release workflow for Ananke.

The project follows a structured branching and release strategy based on conventional commits and automated versioning.

Overview

  • main is the stable production branch
  • development is the staging branch
  • feature work happens in dedicated branches
  • releases and pre-releases are automated via npm scripts

Versioning

  • Version numbers are determined automatically using conventional commits
  • Do not manually set version numbers
  • Commit messages must follow the conventional commits specification

Examples:

  • feat: add new layout option
  • fix: correct mobile navigation
  • docs: update configuration guide

Branching Model

main

  • Contains only stable, released code
  • Updated only via rebase from development
  • Tagged for official releases

development

  • Acts as staging environment
  • Receives all feature and fix changes
  • Used for testing before release
  • Hosts pre-releases

feature branches

  • All work must happen in dedicated branches
  • Branch from development
  • Naming is flexible but should be descriptive

Examples:

  • feature/header-redesign
  • fix/mobile-menu
  • docs/improve-installation

Pull Request Workflow

  • All pull requests must target development
  • No direct commits to main or development

Merging rules

  • Feature branches → development: squash merge
  • development → main: rebase

This ensures:

  • clean history in main
  • meaningful commit grouping in development

Release Types

Pre-releases

Used for testing and validation.

npm run release:pre
  • Created from development
  • Marked as pre-release
  • Used for validation before stable release

Stable releases

npm run release
  • Created from main
  • Tagged as official release
  • Represents stable production state

Release Flow

Typical flow:

  1. Create feature branch from development
  2. Open PR → merge (squash) into development
  3. Test changes on development
  4. Create pre-release if needed
  5. Rebase development → main
  6. Run stable release on main