We use a modified Semantic Versioning (SemVer) for our project. The version format is MAJOR.MINOR.RELEASE, where:
MAJORversion increments indicate incompatible API changes.MINORversion increments indicate addition of backward-compatible functionalities.RELEASEversion increments for each pre-release and release candidate, and is reset to0for final releases.
All versions with MAJOR version as 0 are considered beta, including final releases.
- Beta versions (pre-releases and final releases):
0.MINOR.RELEASE, whereMINORandRELEASEare incremented as per changes. - Release candidates:
0.MINOR.RELEASE, whereRELEASEis incremented for each release candidate.
Examples of beta versions:
- Beta:
0.1.1,0.1.2,0.2.1, etc. - Beta (final release):
0.28.0,0.29.0,0.30.0, etc. - Release candidate:
0.28.4,0.28.5,0.28.6, etc.
Once the project reaches 1.0.0, the versioning will follow the original scheme:
- Pre-release versions:
MAJOR.MINOR.RELEASE, whereRELEASEis incremented for each pre-release. - Release candidates:
MAJOR.MINOR.RELEASE, whereRELEASEis incremented for each release candidate. - Final releases:
MAJOR.MINOR.0.
Examples of versions after 1.0.0:
- Pre-release (alpha):
1.28.1,1.28.2,1.28.3, etc. - Release candidate:
1.28.4,1.28.5,1.28.6, etc. - Final release:
1.28.0,1.29.0,1.30.0, etc.
- All packages, including the VSCode extension, use the same versioning scheme.
- Users can determine whether they're running a beta version, a pre-release, a release candidate, or a final release by looking at the version number.
- The versioning scheme is simple and consistent, making it easy to automate with npm scripts and GitHub workflows.
- The versioning scheme adheres to VSCode's versioning constraints.
- The versioning scheme allows for pre-releases for each commit, the ability to tag release candidates, and published releases.
- All versions before
1.0.0are considered beta, including final releases, aligning with the new project requirement.