LibEmiddle follows Semantic Versioning (SemVer) with a structured branching strategy to maintain multiple versions and ensure backward compatibility.
MAJOR.MINOR.PATCH[-PRERELEASE][+BUILD]
- MAJOR: Breaking changes to the public API or protocol
- MINOR: New features that are backward compatible
- PATCH: Bug fixes that are backward compatible
- PRERELEASE: Optional pre-release identifiers (alpha, beta, rc)
- BUILD: Optional build metadata
-
main- Current stable release (v2.x.x)- Contains the latest stable version
- All releases are tagged from this branch
- Protected branch requiring PR reviews
-
legacy-1.0- Legacy version 1.x maintenance- Contains version 1.x.x codebase
- Only receives critical security fixes and bug fixes
- No new features
-
experimental- Development branch (future v3.x.x)- Integration branch for new features and experimental work
- Base branch for feature branches
- Merged to main when ready for release
feature/*- New featuresbugfix/*- Bug fixeshotfix/*- Critical fixes for productionrelease/*- Release preparation
- Main Branch: v2.0.0+ (Current stable)
- Legacy Branch: v1.x.x (Maintenance only)
The protocol version is managed separately in LibEmiddle.Domain/Constants/ProtocolVersion.cs:
public static class ProtocolVersion
{
public const int MAJOR_VERSION = 2;
public const int MINOR_VERSION = 0;
public const string? LEGACY_VERSION = "1.0";
}Version numbers are centrally managed in:
Directory.Build.props- Global version prefix- Individual
.csprojfiles - Project-specific versions
- Create
release/vX.0.0branch fromexperimental - Update version numbers in all relevant files
- Update protocol version if needed
- Run full test suite
- Create PR to
main - Tag release after merge
- Create new legacy branch for previous major version
- Create
release/vX.Y.0branch fromexperimental - Update version numbers
- Run full test suite
- Create PR to
main - Tag release after merge
- Create
hotfix/vX.Y.Zbranch frommain - Fix the issue
- Update version numbers
- Create PR to
main - Tag release after merge
- Cherry-pick to
experimentalif needed
- Create
hotfix/legacy-1.0-vX.Y.Zbranch fromlegacy-1.0 - Apply critical fixes only
- Update version numbers
- Create PR to
legacy-1.0 - Tag release after merge
- Version numbers are automatically incremented based on branch patterns
- Pre-release versions for feature branches
- Stable versions for main branch releases
- Main: Full build, test, and package
- Legacy-1.0: Security and critical fixes only
- Experimental: Continuous integration builds
- Feature branches: PR validation builds
- Review breaking changes in CHANGELOG.md
- Update protocol handling for new version
- Test compatibility with existing data
- Follow migration guide in documentation
- v2.x can read v1.x protocol messages (with limitations)
- v1.x cannot read v2.x protocol messages
- Data migration tools provided for major version upgrades
| Version | Status | Support Level | End of Life |
|---|---|---|---|
| 2.x.x | Current | Full support | TBD |
| 1.x.x | Legacy | Security fixes only | 2025-12-31 |
git describe --tags --abbrev=0git tag -a v2.0.0 -m "Release version 2.0.0"
git push origin v2.0.0git checkout legacy-1.0