Improvements in cyfs-services version design

[lurenpluto]

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?

[streetycat]

I support adopting a more standardized approach, so that more developers and products can easily adapt to us. Is it possible to change the format after a certain major version?

[weiqiushi]

The current four-digit version number rule comes from the windows desktop program era, and the Windows operating system itself still uses a similar rule at present. This rule is indeed different from the currently popular semver rule. But it also has some advantages:

• Easy to identify the release channel
  Unlike most of the current open source projects, CYFS is different from the release channel. Different channels do not communicate with each other, and each has its own release schedule.
  The current semver rules are not good enough to represent the channel distinction. Using a pre-release version number 1.0.x-channel, or a build metadata field 1.0.x+channel can cause confusion in versioning.
• Suitable for current continuous integration solutions
  Currently, official binary builds are continuously integrated and the Build number is always self-incrementing. It is similar to the version number of windows.
  With semver, the general scheme is that the build number is reset for each version (1.0.x-rc1, 1.0.x-rc2...1.0.x-rc10, 1.0.x official version), so that does not match our CI rules
  If the build number is always self-incrementing, the version number looks weird (1.0.x-rc720, 1.0.x-rc721...1.0.x-rc730), and how to define the version number of the 1.0.x without rc release?