Define the meaning of the release versioning

[caribpa]

As correctly identified by @Maijin here, there's currently no formal agreement of the meaning of the x.0.0, 0.x.0, and 0.0.x releases.

I propose following the Semantic Versioning specification 2.0.0, which is the most commonly used.
Quoting the summary from their page:

Summary

Given a version number MAJOR.MINOR.PATCH, increment the:

• MAJOR version when you make incompatible API changes,
• MINOR version when you add functionality in a backwards compatible manner, and
• PATCH version when you make backwards compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

Note that the specification excludes the development versions:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

@ret2libc, @XVilka, @thestr4ng3r, @ITAYC0HEN, @Maijin, @kazarmy, @wargio, @yossizap, @08a, @pelijah, @officialcjunior, what do you think?

[thestr4ng3r]

The versioning scheme and its meanings were already discussed and specified internally. In short, it will indeed strictly follow semantic versioning.

[caribpa]

Perfect 🎉. To prevent these misunderstandings (or people from forgetting) in the future it could be a good idea to place these internal decisions somewhere (maybe in DEVELOPERS.md?) 🙂

[ret2libc]

As @thestr4ng3r said, we already have that defined, we probably just need to publish this somewhere (maybe adjust something?). That's what we have:

1. MAJOR version when you make incompatible public API changes,
2. MINOR version when you add functionality in a backwards compatible manner, and
3. PATCH version when you make backwards compatible bug fixes.

• As of now, the Public API of rizin is its commands and CLI arguments only and C API is not. In the future, as the C API will improve, it may be considered public API as well.
• Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
• As soon as 1.0.0 is released, the above rules regarding major/minor/patch must be respected. The decision which kind of release to make is solely based on these rules and not on time, the amount or size of changes.

We chose to consider the commands and CLI arguments as the API we are going to version because the C api is too big and unstable right now. Also, it probably doesn't make sense to have a single version for RzBin, RzIO, RzAsm, etc., which all have different APIs and, potentially, specific plugins that don't necessarily have anything to do with other modules.

In the future, we may want to re-think how to provide proper versioning for each library, but that's not going to happen too soon probably.

[caribpa]

That's ok for now, whenever #273 is done we could think about versioning each library.