| name | yabgp-release-workflow |
| description | This document defines the development, version management, and release workflow for the yabgp project. All contributors and maintainers must adhere to these guidelines. |
YABGP Development Workflow and Versioning Standards
Core Principles
- Branch Management:
master: Main development branch, always contains the latest development code.stable/X.Y.x: Stable release branch, used for maintaining released versions (e.g., stable/0.9.x).
- Versioning Standards:
- Follows PEP 440 standards.
- Version number is defined in the
yabgp/__init__.py file.
Detailed Workflow
I. Development Phase
- Current Status: Working on the next feature release (e.g.,
0.9.0).
- Version Number: The version on the
master branch should have a .dev0 suffix (e.g., 0.9.0.dev0).
- Workflow:
- Developer forks the project to their personal repository.
- Create a feature branch based on
master.
- After development is complete, submit a Pull Request (PR) to the
master branch of smartbgp/yabgp.
- Merge after review approval.
II. Testing Phase
- Trigger: Feature development is basically complete, ready for the code freeze and testing period.
- Workflow:
- Tagging: After code merge, create a TAG on the corresponding commit in the
master branch (e.g., v0.9.0a1).
- Iteration: If bugs are found, fix them and repeat the above step, incrementing the suffix (e.g.,
0.9.0a2, 0.9.0a3, etc.).
III. Release Phase
- Trigger: Testing passed, ready to release the official version.
- Workflow:
- Lock Version: Maintainer submits a PR to change
yabgp/__init__.py to the official version number (remove suffix, e.g., 0.9.0).
- Merge and Branch: After the PR is merged into
master:
- Create a new stable branch based on this commit:
stable/0.9.x.
- Create an official TAG on the
stable/0.9.x branch: v0.9.0.
- Start Next Cycle: Submit a new PR on the
master branch to update the version number to the next development version (e.g., 0.10.0.dev0) to distinguish released code from new development code.
IV. Maintenance Phase (Hotfix)
- Scenario: A serious bug is found in a released version (e.g.,
0.9.0).
- Workflow:
- Submit fix code on the
stable/0.9.x branch.
- Update the version number on
stable/0.9.x to 0.9.1.
- Create TAG
v0.9.1 and release.
- Important: Cherry-pick or merge the fix code back to the
master branch (if master also has this bug).
Version Lifecycle Table
| Phase | Branch | __version__ | TAG | Action |
|---|
| Development | master | 0.9.0.dev0 | - | Developer fork → Develop → PR → Merge |
| Testing | master | 0.9.0.dev0 | 0.9.0a1, 0.9.0a2 | Create TAG on stable commit |
| Release | master | 0.9.0 | - | Remove .dev0, Merge PR |
| Release | stable/0.9.x | 0.9.0 | 0.9.0 | Create stable branch, create official TAG |
| Next Version | master | 0.10.0.dev0 | - | Update version to next dev version |
Flowchart
┌─────────────────────────────────────────────────────────────────────────────┐
│ YABGP Release Workflow │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ master branch │
│ ═══════════════════════════════════════════════════════════════════════► │
│ │ │ │ │ │ │ │
│ │ 0.9.0 │ feat A │ feat B │ bugfix │ 0.9.0 │ 0.10.0 │
│ │ .dev0 │ │ │ │ (remove │ .dev0 │
│ │ │ │ │ │ dev0) │ │
│ │ │ ▼ ▼ │ │ │
│ │ │ TAG:0.9.0a1 TAG:0.9.0a2│ │ │
│ │ │ │ │ │
│ │ │ ▼ │ │
│ │ │ ┌────────┴────────┐│ │
│ │ │ │ stable/0.9.x ││ │
│ │ │ │ ════════════► ││ │
│ │ │ │ │ ││ │
│ │ │ │ TAG:0.9.0 ││ │
│ │ │ └─────────────────┘│ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
Version Number Quick Reference
Patch Release
Development: 0.9.1.dev0
Testing: TAG 0.9.1a1, 0.9.1a2
Release: Branch stable/0.9.x, TAG 0.9.1
Minor Release
Development: 0.10.0.dev0
Testing: TAG 0.10.0a1, 0.10.0a2
Release: Branch stable/0.10.x, TAG 0.10.0
Checklist
Before Developer Submits PR
Before Maintainer Creates Test TAG
Before Maintainer Releases Official Version
References
