---

1. Core Strategy and Principles

The main reason for this strategy is to keep mainnet and testnet changes strictly separate. This isolation is critical for decentralized systems where network-specific configurations must remain distinct to prevent cross-network conflicts or downtime.

• Mainnet Namespace: Uses /adcs.

• Testnet Namespace: Uses /adcstestnet.

The overall goal is to ensure code quality, proper testing, and safe deployments across all environments.

---

2. Branch Structure and Descriptions

The strategy defines four long-lived base branches for production and continuous integration, and three types of short-lived branches for development and urgent fixes.

Branch Name	Purpose	Protection/Approval Required	Deployment	Lifecycle
mainnet	Production code for the mainnet network.	High - Requires staging approval.	Mainnet environment.	Long-lived, stable releases only.
testnet	Production code for the testnet network.	Medium - Requires development approval.	Testnet environment.	Long-lived, active testing.
dev-mainnet	Development code for the mainnet network.	Low - Requires feature branch approval.	Local/Development network.	Long-lived, continuous integration.
dev-testnet	Development code for the testnet network.	Low - Requires feature branch approval.	Local/Development network.	Long-lived, continuous integration.
feature/*	Individual feature development.	None - Developer controlled.	Local development.	Short-lived, merged to development.
bug/*	Bug fixes and issue resolution.	None - Developer controlled.	Local development.	Short-lived, merged to development.
hotfix/*	Critical production fixes.	High - Requires immediate approval.	Direct to mainnet (if critical).	Very short-lived, emergency fixes.

---

3. Development and Promotion Workflow

Branching Workflow (Feature/Bug)

1. Start: An issue is raised.

2. Create Branch: Create a feature/* or bug/* branch from the appropriate development branch (dev-mainnet or dev-testnet).

3. Develop: Develop and test the changes locally.

4. Create PR: Create a Pull Request (PR) targeting the respective development branch.

5. Quality Gate: Code review and approval are required.

6. Merge: Merge to the development branch (dev-mainnet or dev-testnet).

Promotion to Production Branch

Promotion is achieved by creating a PR from the development branch to the corresponding production branch, requiring specific high-level approvals (Quality Gates):

Promotion Path	Required Approval (Quality Gate)
dev-testnet → testnet	QA approval required.
dev-mainnet → mainnet	Release manager approval required.

---

4. Pull Request (PR) Process Requirements

PRs must meet different requirements depending on their destination:

Target Branch	Minimum PR Requirements
dev-mainnet / dev-testnet	Code review (min. 1 approver), All tests passing, Documentation updated.
testnet	QA approval required, Testnet-specific changes documented, All integration tests passing.
mainnet	Release manager approval required, Mainnet-specific changes documented, All integration tests passing, Release notes prepared.

---

5. Release Management and Versioning

Release Management

Releases are prepared by creating a temporary release branch from the respective production branch:

• Mainnet: mainnet → release/v1.2.3

• Testnet: testnet → release/v1.2.3-testnet

Steps: Final release preparation (version bump, documentation), Tag the release, and then delete the release branch.

Semantic Versioning (SemVer)

The repositories follow the Major.Minor.Patch SemVer standard:

• Major: Used for breaking changes (e.g., v1.0.0 → v2.0.0).

• Minor: Used for new features (e.g., v1.1.0 → v1.2.0).

• Patch: Used for bug fixes (e.g., v1.1.1 → v1.1.2).

Release Tags must use the format v1.2.3, be created from the main branch, and include release notes. Signed commits are recommended.