1. The stage version Description
* Mention test version: This version eliminates 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 BUG.
* Verify version beta: This version is already quite mature, basically BUG caused the error does not exist, the issue was tested on individual channels.
* Official version release: 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 main version.
2. naming convention
2.1 naming convention
The software version number consists of four parts, the first one is the major version number, the second one is a minor version number, 1 for the third stage of the version number, the fourth part is the version number of the Greek alphabet, the Greek alphabet version number a total of 2 species, namely: beta, release. For example: 2.1.1.7434_beta.
{
1, using semantic software version naming system must define a common API. This API can be declared in the code, or use a strict definition of the document. Anyway do, it should be clear.
2, the normal version of XYZ and must be used in the form X / Y / Z is a non-negative integer. X is the major version, Y is the minor version number, Z is a patch version number. The version number is required for each can only grow 1. For example: 1.9.0-> 1.10.0-> 1.11.0.
3, when the growth in the major version number, minor version number and patch version numbers must be cleared. When the minor version number increase, and patch version must be cleared. For example: 1.1.9-> 2.0.0,2.1.7-> 2.2.0.
4, once the pack has released a version, that version of the content must not be changed. Any changes must be published as a new version.
5, major version number 0 (0.yz) is used for performing the initial development. Anything could change at any time. Public API at this time should be considered to be constantly changing.
6, version 1.0.0 began to define the public API. This version and later versions of growth will depend on the number of common API and how it changes.
7, if a single sub-products are backward compatible with any bug fixes occurs, the patch version number Z (xyZ | x> 0) must increase 1. "Bug fix" is defined as restoration work to repair abnormal behavior conducted internally.
8, if a single child product was new and is backward compatible public API to add, optimize, modify, minor version number Y (xYz | x> 0) must increase 1. If any public API has been marked as "expired", the minor version number must grow by 1; if there are a large number of new features or improvements occurred in the internal code, the minor version number may grow 1; which may also include patch level changes. When the minor version number increase patch version number must be cleared .
9, if a single sub-products are not compatible with any downward changes to the public API, or by two or more sub-products also released new features, or main products open up new business models, the major version number X (Xyz | X> 0 ) must grow 1. Which may also contain minor version and patch version level changes. When the major version number grew minor version number and patch version numbers must be cleared.
2.2 version number given to modify the rules
* Major version number (1): When the function is greater changes, such as increasing the number of modules or changes in the overall structure. This version is determined by the total number of projects for which it is modified.
* Minor version number (1): When a certain function increases or changes, such as increased the access control, and other functions to add custom view. This version number is determined by the product manager whether to modify.
* Stage version number (1): Generally Bug fix or some small changes, we 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 team in charge of whether to modify.
* Random version: This version is responsible for the project team decided whether to modify.
* Greek alphabet version (beta): This version number for the development phase which marked the current version of the software is, you need to modify this version when the software into another stage.
Put into the test version of the beta version to verify decided by the person in charge of the project to test whether the modification.
Enter the beta version to verify the official version release is determined by the overall project for which it is modified.
3. Content Management version
l main versions based team management;
All versions of the main demand, a demand put forward their views in the pool, each planning iteration, the product manager responsible for managing the version of the content, the user needs to write the story of this iteration needs to do to go into management, for example, "demand version table"
Demand Version 3.1
The importance of scene numbering module role
Each cycle of the full content version needs a common awareness, the demand for this content version table may also be public forums to go.
Requirements documents are on SVN, the project to facilitate the students to understand.
l Other versions of branch and gray channels are managed by the commercial team.
Example "Version Request Form"
4. versions of the development process
l GIT intervention tools developed from next month
Determine the need to develop new capabilities in the branch when l iteration plan
L The project developed a coding current development branch from the trunk build, develop new features for use
l project testing phase, the branch hit version for testing and acceptance
When l Debug, bug fixing on the development branch
After l Beta version confirmed by (total charge of confirmation), function code together into the Backbone
l test version Submitted: daily 15:00 to play test kits before and after work
The on-line version management
Completed within mention test version of the project, jointly test.
Verify beta version requires students mail notification operations, the key person in charge of the project, the general manager, and comes in the mail this update description, the channel line description.
The total time required to update the official version of the release project leader confirm to update all servers all channels need to formalize mail notification whole project team members, general manager, and comes in the mail this update instructions.
6. version Records Management
Cases of "product version management record"
links: https://www.jianshu.com/p/54f4351828da
Source: Jane books