YABGP Development Workflow and Versioning Standards

Core Principles

1. 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).
2. 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:
  1. Developer forks the project to their personal repository.
  2. Create a feature branch based on master.
  3. After development is complete, submit a Pull Request (PR) to the master branch of smartbgp/yabgp.
  4. Merge after review approval.

II. Testing Phase

• Trigger: Feature development is basically complete, ready for the code freeze and testing period.
• Workflow:
  1. Tagging: After code merge, create a TAG on the corresponding commit in the master branch (e.g., v0.9.0a1).
  2. 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:
  1. Lock Version: Maintainer submits a PR to change yabgp/__init__.py to the official version number (remove suffix, e.g., 0.9.0).
  2. 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.
  3. 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:
  1. Submit fix code on the stable/0.9.x branch.
  2. Update the version number on stable/0.9.x to 0.9.1.
  3. Create TAG v0.9.1 and release.
  4. 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

• Code is based on the latest master branch
• Local tests passed
• Version number not modified

Before Maintainer Creates Test TAG

• Code is based on the latest master branch
• TAG name follows standards (e.g., 0.9.0a1)

Before Maintainer Releases Official Version

• Version number updated from .dev0 to official version
• stable/X.Y.x branch created
• Official TAG created on stable/X.Y.x branch
• master branch version updated to next development version

References

• PEP 440 - Version Identification and Dependency Specification
• Python Packaging User Guide - Version Specifiers
• Semantic Versioning 2.0.0