I tried to learn it from wiki Software Versioning control , but I could't understand very well. I know the last numbers means that many bugs fixed and I already got something from wiki. but what is the main difference between the versions of app, like 1.2.1 and 2.4.5 ? is there any source for quick explanation? When I update my app on play store, how should I choose version? if I change API should I change the last digits of version numbers from 1.1.2 to 1.1.3 or I must change the first number like 1.1.2 to the 2.1.2? Thanks.
The answer depends on the development team's choice of a versioning scheme. The most common scheme in my experience is the Semantic Versioning scheme in which the three numbers have a semantic value attached to them.
What is the main difference between the versions of app, like 1.2.1 and 2.4.5?
This would indicate that the newer software 2.4.5 has a breaking change and could result in problems for you or any software that consumes that code.
If I change API should I change the last digits of version numbers from 1.1.2 to 1.1.3 or I must change the first number like 1.1.2 to the 2.1.2?
In this case you should choose the version 2.1.2 if the change risks breaking other code that consumes the API, and you should choose 1.1.2 if your change includes something that adds to the API but does not take away from the functionality or interface of the API.
When I update my app on play store, how should I choose version?
Choose what makes sense to you or your team. Sometimes if it controlled by the platform you may not be able to choose, but lean on the side of conforming to the environment you are put in. Meaning follow the versioning conventions of the platform you are developing for.
The first number in the sequence (1.x.x) is the major version and this semantically means that the software has a breaking change that could affect any other software that depends on it. For example, you could have an API that completely changes the URI path in an upgraded version from 1.x.x to 2.x.x.
Minor versions are changes to the code that do not reflect breaking changes, but are significant enough to warrant a version increase. More often then not this includes additions to the code that add functionality and does not break it. So if you added a new endpoint to an existing API and kept all other endpoints the same then the API's version could be increased from x.1.x to x.2.x.
The last number in the scheme stands for the bug/build version depending on how you want to look at it. In teams like mine we use the third number to automatically increase the version for every push to our CI/CD pipeline that pushes a version artifact to our repository. This also could be used for bug fixes and hot fixes that come up in the lifecycle of your application. For example, x.x.1 to x.x.2.
This is not the only versioning scheme out there, and not the last one to be invented. However, this scheme seems to have traction in the industry at the movement and is worth learning. Plus, it enables some cool automation tricks on your CI/CD pipeline when you have meaning behind version numbers and commit standards that align with them. (Conventional Commits)