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

Question

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

Navigation

#1 by (1 votes)

1

According to the site link

Given a MAJOR.MINOR.PATCH version number, increase to:


MAJOR version: When you make incompatible changes in the API

Minor version: when adding features while maintaining compatibility

Patch (PATCH) version: when to fix failures while maintaining compatibility.


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

Reading this passage in the FAQ:

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

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

How do I know when to release version 1.0.0?

If your software is being used in production, it should probably already be 1.0.0. If you have a stable API that users depend on, it should be 1.0.0. If you're worrying a lot about backward compatibility, it should already be 1.0.0.

I understood what 0.x.x is only for development and when it is stable then we should migrate to 1.0.0, but what I did not understand is how this works along with Alpha, Beta and RC. In the case Alpha and Beta are not stabilized yet, just maybe the RC (Release Candidate).

As I understand it Alpha is usually "distributed" among developers or a group that will experiment.

Questions:

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

versionamento

asked by anonymous 19.02.2016 / 21:09

1 answer

Help between communication between clients WEBSERVICE REST - JSON - JAVA Hide certain quantity

score 1 · Answer 1

What Visual Studio says, it's different than versioning, not totally, but it changes some things that make sense, what are the major, minor, build and revision versions, showing below , respectively:

Major . Minor . Build . Revision

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

A big change: Increment Major , usually 1, also increase when Minor is too high.
Some new features: Increment Minor , usually I base the number that I will set depending on the new feature 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 compilation, so I also define how much it will increase depending on how many bugs have been fixed.
Minor changes or corrections: Increase Revision , just a little revision in the application, a misspelling or something.

I do not know if it's okay to set a version standard for all applications, why does not this pattern exist? How can I prove it? There are applications with their due versions ( no, the examples below are nonexistent ):

Zézin application, version 1.2.5.12
FooBar application, version 2015.2162.122.5
HelloWorld application, version 0.1262.1.25

Now tell me, from the application zézin to FooBar, had a lot of modification regarding its versions, correct?

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

When you think your application is good, running smooth with no bugs or problems, you release a Beta, Beta comes from the Final, and you can get more Betas and endings forever, but you can never get one Alpha after a Beta or Final .