Software version naming convention and the stage instructions

Foreword

Many developers have not experienced continuous product iterative process, basically a done up to go through one or two versions of the iteration, the project will basically be transferred to another group or leaving after such things constantly repeat until the leave the industry.

Developers three months to develop a version, positioning version1, how to upgrade if there is bug, fix this version of it? May be version2, after fix this bug, if there is bug, it might continue version3., If this continues, not to the product line, this version you will be great, and it is difficult to remember which version of what function. If the line on future products, but also to upgrade, you can imagine, after this continues, it may reach the version9999 ...

Naming format

3 kinds of version control more common naming format: GNU style version number naming format, Windows-style version number naming format, .Net Framework style version number naming format.

GNU style version number naming format

The main sub-version number version number [revision number [build numbers].]
Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Number]]
Example:1.2.1, 2.0, 5.0.0 build-13124

Windows-style version number naming format

The main sub-version number version number [revision number [build numbers].]
Major_Version_Number.Minor_Version_Number[Revision_Number[.Build_Number]]
Example:1.21, 2.0

.Net Framework style version number naming format

. [. Compiled version number [revision number]] promoter major version number The version number
Major_Version_Number.Minor_Version_Number[.Build_Number[.Revision_Number]]
version number of two to four parts: the major version, minor version number, build number and revision number. The major version number and minor version number is mandatory; internal version number and revision number is optional, but if you define a part of the revision number, the build number is mandatory. All part of the definition must be an integer greater than or equal to 0.

These parts should be used according to the following convention:

Major: Program with the same name but different version numbers of the main assembly are not interchangeable. For example, this applies to a lot of rewriting of the product, which makes it impossible to rewrite backward compatibility.

Minor: If the two assemblies and the major version number of the same name, while the second number of different versions, which indicates significantly enhanced, but take care of backward compatibility. For example, this applies to the new version of the product revision or fully backward compatible.

Build: Different build number represents a recompilation of the same source made. This is suitable for the situation to change processor platform or compiler.

Revision: Name, major version number and minor version numbers are the same but the revision number of different assemblies should be completely interchangeable. This applies to previously released assembly repair security vulnerabilities.

Follow-up version of the assembly only internal version number or a different revision number is considered the previous version of the patch (Hotfix) update.

Because the current software on the market are basically moving end of, so here we introduce the GNU style.

Software version Phase Description

Base version: This version indicates that the software is only a fake page link usually includes all the features and page layout, but the pages do not function complete implementation, just as a whole infrastructure of the site.
Alpha version: this version of the software at this stage indicates that the main function is implemented in software-based, usually only exchange in-house software developers, in general, the more Bug version of the software, we need to continue to modify.
Beta version: This version relative to the α version has been greatly improved, eliminating a serious mistake, but still there are some flaws, need to go through several tests to further eliminate, major changes in this version of such software UI .
RC version: This version is already quite mature, basically BUG caused the error does not exist, and the official version of the upcoming release of almost the same.
Release version: This version means "final version", after a series of earlier versions of the beta, after all, there will be a formal version, it is to deliver a final version of the user. This version is also sometimes referred to as the standard version. Under normal circumstances, Release word does not appear in the form of software on the cover, replaced by the symbol (R).

Version naming convention

The software version number consists of four parts:

The first part is the major version number
The second part is the minor version number
The third part is the stage version number
The fourth part is the date of the version number is incremented the version number of the Greek alphabet

Version Number Modification Rule

主版本号修改When the function have a greater change, such as increasing the number of modules or changes in the overall structure. This version number is determined by whether the project changes.
子版本号修改When an increase or a certain function change, such as increase of access control, and other functions to add custom views. This version number is determined by whether the project changes.
阶段版本号修改Bug fixes generally or some small changes, you should always publish revised edition, limited time interval, fix a serious bug to publish a revised edition. This version number is determined by the project manager whether to modify.
日期版本号The current record date for the modified project, every day of the modified project will need to change the date of the version number. This version number is determined by whether the developer to modify.
希腊字母版本号This version number used to label the current version of the software which is in the development stage, we need to modify this version when the software into another stage. This version number is determined by whether the project changes.

The version number of milestones

Stage name	Phase identification
Demand Control	a
design phase	b
Coding stage	c
unit test	d
Unit testing modifications	e
Integration Testing	f
Integration testing modifications	g
System test	h
Modify System Test	i
Acceptance Test	j
Acceptance testing modifications	k