## BDLedger Release Versioning

Major releases: `YY.0M.PatchNumber`

Alpha releases of a future release: `YY.0M-alpha.MMMDD` 

Beta releases of a future release: `YY.0M-beta.MMMDD`

Evaluation versions: `eval-YY.0M.PatchNumber`

### Versioning Scheme

**YY**: Short year which indicates which year the release was made GA.

**0M**: Zero padded month indicating the month that the release was made GA.

**PatchNumber**: Patch releases are focused on bug fixes and are backward compatible. If a bug fix has a breaking change it will not be released until the next major release but will be available as a beta.

**Beta Releases**: Beta releases are available before the GA and are cut from the release branch, which will be in sync with the master branch. Their naming scheme contains the release the beta is destined for (YY.0M.0-beta.MMMDD), and the date that the beta was made available (YY.0M.0-beta.MMMDD). Before GA we will have a period of code freeze on the release branch and then we will make the release GA. This is done to make sure we are releasing a high quality and stable product. After the release is GA, every new feature will then go to the next release branch.

### Versioning for BDLedger SDKs and Tools

We will release any SDK or tool that has a breaking change and will sync its release number with BDLedger. So at any given time, its release number will be in sync with the earliest compatible BDLedger version.

For SDK-versioning, there’s a special exception for the Go SDK. dgo versions would include an extra digit in the YY number to allow for breaking changes within the year. In a hypothetical scenario, they could be called v200.03.0, v201.07.0, v202.11.0 if there are multiple breaking API changes within the year. This versioning scheme still correlates to BDLedger versions, yet supports Go Modules which mandates using Semantic Versioning.

## Deployment

See [BDLedger Deployment](https://public.internetapi.cn/?dir=releases/bdledger/deployment).