How to name the APP version number correctly and elegantly?

As a mobile product manager, I often plan APP version iterations, so it is inevitable to determine the version number for the APP. In most cases, I may just decide the version number on a whim.

Some companies may have dedicated project managers responsible for version management and version number naming, but most small companies may have product managers to do this work.

After collecting some information online, I found that there are many standards and principles for naming APP version numbers. This article will share these standards and principles with you.

1. Why should we standardize the naming of APP version numbers?

First of all, it is necessary to clarify which personnel need to use the APP version number. The first is the product manager, the second is the developer, the third is the project manager, and the fourth is the user.

For product managers, APP version iterations are basically initiated by product managers. Therefore, in many cases, product managers roughly divide the version numbers when conducting demand management and version planning. The version numbers can help product managers better and more clearly screen and determine the requirements of each version.

For developers, the version number is directly related to the code. Often, different versions are cross-developed and may be developed at the same time. In order to ensure the standardization and clarity of the code and avoid cross-confusion between different versions, the version number is an extremely important link.

For project managers, the version number is a unique identifier in requirement management. Work needs to be managed and distributed based on the version number. It is also for better communication and marking during the software product life cycle.

For users, although the version number is just a string of numbers, it gives users the perception that it is a constantly updated number, and they can use the version number to determine whether their APP is the latest.

2. Composition and specification of APP version number

In many cases, the version number may only follow two principles and specifications, namely, the basic principle that the version number is unique and is a string of numbers.

Before introducing the naming conventions and principles of APP version numbers, we first need to understand the composition of APP version numbers.

The software version number consists of four parts: <Main version number> <Sub version number> <Phase version number> <Date version number plus Greek letter version number>

There are five types of Greek version numbers: base, alpha, beta, RC, and Release. For example: 2.1.0.181209_Release.

The following is a brief description of the Greek letter version number:

• Alpha version: also called α version (development environment), this version is mainly used to implement software functions and is usually only communicated among software developers;
• Beta version: This version has been greatly improved compared to the alpha version, and serious errors have been eliminated, but there are still some defects that need to be further eliminated through multiple tests. The main modification of this version is the software UI;
• RC version: This version is quite mature and basically has no bugs that may cause errors. It is almost the same as the official version to be released soon, and the version that the testers have basically passed;
• Release version: This version means "final version" or "online version". After a series of beta versions of the previous version, there will be a formal version, which is the version finally delivered to users. This version is sometimes also called the standard version. Generally, Release does not appear on the software cover in the form of words, but instead is replaced by a symbol (R).

For most APPs, the GNU-style version number management strategy is generally adopted. The complete version number of the APP consists of three groups of numbers "<main version number.><sub-version number>.<stage version number>", that is, XYZ, where X, Y, and Z are all positive integers.

3. Naming and modification rules of APP version number

1. Major version number

• When there are major changes in multiple main modules of an APP, generally, for example, a new TAB is added to the APP, the entire product structure is changed; or new functions or services are added, such as WeChat launching a wallet, and Douyin launching live broadcasting;
• The starting value of the major version number is 0 or 1. It is up to the product manager to decide whether the major version number needs to be modified (PS: most of the time, the boss may need to make the final decision).

2. Subversion number

• The initial value of the sub-version number is 0;
• When a relatively small number of main modules of the APP undergoes major changes or new modules are added (involving changes to the main logic), or a relatively large number of branch modules undergo major changes or additions, and compared to the main version number, these are only partial changes, such as UI reconstruction of a certain function, optimization of a certain page, etc., the relatively small and large modules need to be defined. Generally, we consider relatively small to be less than 3, and large to be more than 3;
• The maximum value of the sub-version number needs to be determined. Different companies may have a maximum value. For example, the maximum is 9. If it exceeds 9, the main version number needs to be increased by 1. Some companies may not have a maximum value and will only reset the sub-version number to 0 when the main version number is +1. There are no definite principles and specifications here, and the product manager can set the rules himself.

3. Phase version number

• The initial value of the stage version number is 0;
• When to modify the stage version number, usually it is to fix bugs and changes to a few branch modules, such as changes in visuals, styles, interactions, copywriting, etc.
• Generally speaking, if you just want to fix a bug, you can increase the stage version number by 1; if it involves both bug fixes and modifications to a few branch modules, you can increase the stage version number by 2; if it involves modifications to more than 3 branch modules, it is recommended to directly increase the sub-version number by 1.

Summarize

Although the version number is just a string of numbers, it is a meaningful string of numbers for product managers, developers, and users. It can not only standardize the life cycle of the version, but also facilitate communication and work among internal personnel.

It is not rigorous and standardized to name the version number based on your own ideas, and product managers need to pursue perfection. I hope the above APP version naming standards can provide some reference for everyone.