Which versions can be released after testing?

Another question:

What is the name of the software version submitted for formal testing? This version can be directly released if it passes subsequent tests, but you do not know whether the test passes when submitting the test.

Release Candidate edition? Official beta version? In contrast, how do we call a version that cannot be released even if the test passes (for example, due to some features being incomplete )? Informal Beta? Early Beta?

Answer 1: Release Candidate is a common name. From @ Stephen _ wang_7971

Related answer 1.1: Release Candidate (RC, candidate release version), release to manufacture (RTM, factory pressure version), Golden Master (GM, gold version), from @ Cui Qiliang-Beijing ISTQB

Associated answer 1.2: Alpha, beta, then RC, and finally released that can be called GM. From @ sengooma

Answer 1: Unfortunately, the release candidate statement is ambiguous and has two meanings: 1. Candidate Release versions after alpha and beta testing; 2 is the version that completes all the functional features planned to be done.

1 indicates the original meaning of release candidate. The version 2 is earlier than alpha.

Answer 2: Standard version in the system testing phase from @ Alibaba International Quality Assurance Department

Answer 2's comment: "standard version in the system test phase", yes, it means, but it looks like a long time from @ Zhang Keqiang-agile 307

Answer 3: Release the waiting test version. For release version from @ Zhang Keqiang-agile 307

Answer 4: Is it the formal test version during the R & D process or the final release of the test version. The formal test board in R & D can be used only for touch function, performance verification. The final release of the test version indicates that the development is complete, and the release can be launched without any problems after verification. It is easier to separate definitions! From @ 8 Five-color black and white 8

Associated answer 4.1: the official beta version also has this usage. The official beta version is also ambiguous! From @ Zhang Keqiang-agile 307

Associated answer 4.2: I guess the usage of @ 8 Five-color black and white 8 is an extremely minority. I personally do not agree that the official beta version only applies to a function and performance verification. Even if the test passes, it does not meet the release standards. He insulted the word "formal.

Associated answer 4.3: if the test passes the direct release, it is the official version. This official version has not been tested, it will generate the official version-2 stream, and then unlucky, the official version-3. From larrycaiyu

Related Comments: official version, which looks good, is shorter than the release of the tested version from @ zhangkeqiang-agility 307

Related Comments: however, this statement is confused with the version released after the test is passed. It is too formal and not good.

Answer 5: the final version of the test; the version of the test is not the correct version; the version of the test is changed to version 2; the test is definitely not revised; the test is really not revised; from @ Stephen en_wang_7971

Answer 5: although it seems like a joke, this joke reveals the root cause of my question: I already have certain conditions, but I'm not sure if I can pass the test. What should I call it ?, More importantly, how to test it?

Answer 6: ver x. y. Zzz from @ Stephen _wang_7971

Associated answer 6: the realm of using this practice is already higher than that of the RC two-storey building. Only a very small number of companies can build any version at a time as a potential release version, and Microsoft has not yet done so.

If not, what should I do?

Answer 7: Build XXXX. The number is from the version management system. From @ Stephen _ wang_7971

Reply @ stephen_wang_7971: Baoxin software, which has worked before, adopts this method. There is a strict version baseline naming method, which is actually the same as RC1 and RC2. From @ Zhang Keqiang-agile 307

Summary

After discussion, the following statements are recommended:

1. Beta

2. Release the version to be tested

The specific identification methods include:

1. RC1, rc2... RCN --- this is confused with the practice of releasing software after Alpha for large companies.

2. Use multi-segment version numbers directly, such as ver x. y. Zzz. This means that each compilation is a potential release version, but only a few companies can do this. Another similar case should be noted: do not perform a preliminary test on the version number, and pass the preliminary test before giving the version number. If there is no other version ID, this approach violates baseline management, it is 0.1 million miles away from the previous high-end gameplay. If there is another version logo, it is two floors different from the previous high-end gameplay.

3. Build XXXX. The number comes from the version management system. Build indicates the official test version and XXXX indicates the baseline. This is a moderate and good practice.