# Synchronize Testnet and Mainnet Code Versions to Improve Development Reliability

# Synchronize Testnet and Mainnet Code Versions to Improve Development Reliability

## Summary
We request that the Hedera team adopt a synchronized release approach between testnet and mainnet environments. Currently, these environments run on different code versions, which creates significant challenges for developers. This misalignment forces teams to either deploy to mainnet without proper testing or incur additional costs by testing directly on mainnet. Standardizing version parity between environments would align with industry best practices and substantially improve the developer experience.

## Current State
Testnet and mainnet currently operate on different software versions:
- Testnet often runs newer versions with features not yet available on mainnet
- Mainnet sometimes contains fixes or behaviors not reflected in testnet
- The exact differences between environments are not always clearly documented
- Release schedules for each environment appear to be managed independently

## Impact on Development Workflow

This version discrepancy creates several significant challenges:

### 1. Uncertain Deployment Outcomes
When developing and testing on testnet, we cannot guarantee that identical code will work the same way on mainnet due to underlying platform differences. This uncertainty undermines the core purpose of having a test environment.

### 2. Financial Costs
This misalignment forces developers to choose between:
- Testing on mainnet (incurring real HBAR costs for each test)
- Risking production failures due to untested environment differences
- Developing duplicate test suites for both environments
- Creating complex version detection and adaptation code

For our team, this has resulted in approximately:
- many additional development hours per release
- many HBAR spent on mainnet testing that should have been possible on testnet
- Delayed releases and additional QA cycles

### 3. Reduced Developer Confidence
Developers cannot fully trust that testnet behavior represents mainnet behavior, which:
- Discourages thorough testing
- Increases stress during deployments
- Requires defensive coding practices
- Complicates documentation and support

## Industry Best Practices

The industry standard for test/production environments includes:

1. **Environment Parity**: Test environments should mirror production environments as closely as possible, including software versions
2. **Promotion Model**: Code should move through environments (dev → test → prod) rather than environments having different versions
3. **Configuration-Based Differences**: Differences between environments should be configuration-based, not version-based
4. **Clear Documentation**: Any unavoidable differences should be precisely documented
5. **Predictable Release Calendar**: Developers should have visibility into when versions will synchronize

Leading cloud platforms and blockchain networks generally follow this approach:
- AWS, Azure, GCP maintain service version parity across regions/environments
- Ethereum testnets implement the same protocol version as mainnet
- Financial networks maintain protocol-level compatibility between test and production

## Proposed Solution

We respectfully request the following changes:

1. **Synchronized Versioning**: Maintain identical code versions between testnet and mainnet, with testnet upgrades preceding mainnet by a predictable window (e.g., 1-2 weeks)

2. **Clear Release Schedule**: Publish and maintain a release calendar showing when versions will be deployed to each environment

3. **Comprehensive Release Notes**: Document any intentional differences between environments

4. **Environment Flags**: If feature differences are necessary, implement them as configuration flags rather than different codebases

5. **Version APIs**: Add API endpoints to query the exact version and features available in each environment

## Implementation Considerations

We understand this change may require adjustments to the release process:

1. **Gradual Transition**: A phased approach could synchronize versions over several release cycles
2. **Feature Flags**: New features can be disabled in production until fully tested
3. **Preview Environment**: If early feature testing is needed, consider a third "preview" environment rather than making testnet inconsistent with mainnet
4. **Multiple Testnets**: Consider having both a "beta" testnet (ahead of mainnet) and a "mirror" testnet (matching mainnet)

## Business Value

Synchronizing testnet and mainnet versions would provide significant value:

1. **Improved Developer Experience**: More reliable testing leads to faster, more confident development
2. **Higher Quality Applications**: Better testing environments result in fewer production issues
3. **Cost Savings**: Reduced need for mainnet testing saves HBAR and development time
4. **Faster Time-to-Market**: More predictable deployments shorten development cycles
5. **Ecosystem Growth**: A more developer-friendly platform attracts more projects

## Conclusion

Environment version parity is a foundational best practice in software development. Aligning testnet and mainnet versions would significantly improve developer experience, reduce costs, and ultimately lead to higher quality applications on the Hedera network.

We understand that there may be architectural considerations that have led to the current approach. We're happy to discuss this further and assist in any way possible to help implement this important improvement.

No files, tests, or entry points are named. Start by mapping how testnet and mainnet versions and releases are currently managed, then determine which proposed outcome is in scope: synchronized deployments, release documentation, environment flags, or version APIs; completion would require an agreed implementation plan and verifiable parity.

Written by the indexing model from the issue text.