For various historical reasons, we have adopted a four-digit version number, which is one more digit than the common semantic version numbering mechanism to indicate a nightly/beta/product release:
{major}.{minor}.{release}.{patch}
Currently, after cyfs-services enters the release process, each compilation will add the patch version number, because the number of intermediate releases in each release cycle is uncertain, so it is not possible to precisely describe the next version to be released. Specify the version number of the next version precisely (usually use patch to specify)
Seeing that semver's specification suggests using rc (release candidate) to manage intermediate versions in the release cycle, is it possible to adopt a similar mechanism for cyfs-services?
For various historical reasons, we have adopted a four-digit version number, which is one more digit than the common semantic version numbering mechanism to indicate a nightly/beta/product release:
Currently, after cyfs-services enters the release process, each compilation will add the patch version number, because the number of intermediate releases in each release cycle is uncertain, so it is not possible to precisely describe the next version to be released. Specify the version number of the next version precisely (usually use patch to specify)
Seeing that semver's specification suggests using rc (release candidate) to manage intermediate versions in the release cycle, is it possible to adopt a similar mechanism for cyfs-services?