Bitcoin Module Branching Strategy

[AIR-3][AIS-3][BPC-3][AIT-3][RES-3]

This document outlines the branching strategy for Bitcoin-related changes in the Anya-Core project, following the Bitcoin Development Framework v2.5.

Branch Structure

Our branch structure for Bitcoin module development follows a hierarchical model:

main
├── dev
│   ├── feature/bitcoin-core
│   ├── feature/bitcoin-implementation
│   ├── feature/bitcoin-layer2
│   ├── feature/bitcoin-testing
│   └── feature/bitcoin-hexagonal-architecture
└── new-release-candidate-1.0

Branch Descriptions

  • main: Stable production branch with released code only
  • dev: Main development branch with integrated features
  • feature/bitcoin-core: Core Bitcoin protocol implementations
  • feature/bitcoin-implementation: Implementation-specific features
  • feature/bitcoin-layer2: Layer 2 solutions (Lightning, RGB, etc.)
  • feature/bitcoin-testing: Testing infrastructure for Bitcoin modules
  • feature/bitcoin-hexagonal-architecture: Hexagonal architecture implementation for Bitcoin modules

Workflow for Bitcoin Changes

  1. Feature Development
  2. Create a feature branch from the appropriate parent branch
  3. Branch naming should follow the pattern: feature/bitcoin-{component}-{description}

  4. Example: feature/bitcoin-taproot-verification

  5. Commit Standards

  6. All commits must follow the AI labeling standards
  7. Format: [AIR-3][AIS-3][BPC-3] Brief description
  8. AIR-3: AI Requirements
  9. AIS-3: AI Security

  10. BPC-3: Bitcoin Protocol Compliance

  11. Pull Request Process

  12. Create PR targeting the appropriate integration branch
  13. PR title must follow the AI labeling format
  14. PR description must include Bitcoin Development Framework compliance checklist

  15. Require reviews from at least one Bitcoin protocol expert

  16. Testing Requirements

  17. Unit tests: 100% coverage for consensus-critical code
  18. Integration tests: Testnet simulations with 3+ node types

  19. Security tests: Fuzz testing for critical components

  20. Merging Strategy

  21. Squash and merge for small, contained changes
  22. Merge commit for large feature integrations

  23. Always maintain a clean commit history

  24. Branch Lifecycle

  25. Feature branches are deleted after successful merge
  26. Integration branches are periodically synced with their parent branches
  27. Release branches are created from integration branches when ready

Compliance Requirements

All branches must adhere to:

  • BIP standards compliance
  • Hexagonal architecture principles
  • Security validation requirements
  • Documentation standards

This branching strategy ensures orderly development, clear tracking of changes, and maintenance of Bitcoin protocol compliance throughout the development lifecycle.