When to use "0.x. x" and "alpha" in versioning?

Question

According to the website http://semver.org/lang/pt-BR/

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

• Major (Major): when making incompatible changes to the API
• Minor version(MINOR): when adding features while maintaining compatibility
• Patch Version(PATCH): when fix faults maintaining compatibility.

Additional labels for pre-release(pre-release) and build(build) metadata are available as format extension MAJOR.MINOR.PATCH..

Reading this excerpt in the FAQ:

How should I handle revisions in the 0.y. z phase of initial development?

The simplest thing to do is to start your initial development version at 0.1.0 and then increment to a 'minor' version in each subsequent release.

How do I know when to release version 1.0.0?

If your software is being used in production, it should already be probably 1.0.0. If you have a stable API that users have come to depend on, it must be 1.0.0. If you are worried enough about compatibility with previous versions, it should already be 1.0.0.

I understood what the 0.x. x is only for development and when it is stable then we must migrate to 1.0.0, but what I don’t understand is how it works together with Alpha, Beta and RC. In case Alpha and Beta are not stabilized yet, only perhaps the RC (Release Candidate).

From what I understand Alpha is usually "distributed" among developers or a group that will try.

Doubts:

• When to use -alpha and when to use 0.x. x?
• The suffixes Alpha, Beta and RC are only for commercial software (I’m not talking about paid software) such as complete software and the use of 0.x. x would be more code-oriented?

Answer 1

From what Visual Studio says, the classification of the versions is different, not entirely, but it changes some things that make sense, which are the versions Larger, smaller, compilation and revision, showing below, respectively:

Major . Minor . Build . Revision

I use my theory to change the versions of my applications:

• A wonderful change of heart: Increment the Major, generally at 1, also increase when the Minor it’s too high.
• Some new features: Increment the Minor, I usually refer the number I will set depending on the new resource added, for example, if it is something very useful and good, increment in 100 or 200, if it is something small, is between 10 and 99.
• Bug fixes: Increment the Build, in the case of the compilation, then I also define the amount that will increase depending on how many bugs have been fixed.
• Minor modifications or corrections: Increment the Revision, just a little review in the app, a spelling error or something.

I don’t know if the correct thing is to set a version standard for all applications why this pattern does not exist, how can I prove it? There are applications with their proper versions (no, the examples below are non-existent):

• Zézin application, version 1.2.5.12
• Foobar App, version 2015.2162.122.5
• Helloworld Application, version 0.1262.1.25

Now tell me, the zézin app for Foobar, had a lot of modification in relation to its versions, correct?

I always use the Alpha for a phase before the Beta, in my use, Alpha is always before the 1.0, after that comes the version Beta, if necessary can be the Beta and the Final, releasing a Beta and a more stable version, in this case the Final (or in your case, the RC (release)).

When you find that your app is fine, running smooth without bugs or problems, you release a Beta, from the Beta comes the Final, and can come out more Betas and endings forever, but an Alpha can never leave after a Beta or Final.