Software Version Control Specification

Version Control Specifications

1. Overview 1.1 Purpose

The version control specification is used to determine the naming and version number management rules of software configuration items, to ensure that each component and its status of the software are clearly and uniquely identified, and to establish consistency between these parts.

Range: 1.2

The scope of version control includes:

2. Source Code: source code files written in computer programming languages

2. Documentation: technical documents describing software functions and structures, project management documents such as project plans, and various test documents and user documents.

2. Product Package: A runable software system compiled from the source code

2. Product ID

When a software product is approved, the software product identifier is set up to uniquely represent a software product or project. The product identifier is also called a project identifier.

 

2.1 Product Name

When a new product is approved, the product name is assigned to the product. When an existing product is upgraded, the product name of the previous version is used.

Product names include:

2. Chinese Product Name: such as manufacturing execution system and Warehouse Management System

2. English Product Name: for example, Manufacturing Execution Systems and Warehouse Management System

2. Product Abbreviation: MES, WMS

The product name is used to compile relevant documents and release products.

The product name is not a unique identifier of a product. It must be used with the version number to identify a specific product.

2.2 version

The version number is used to identify products in different states in the development, test, and delivery stages. The version number format is:

<Major version number>. <minor version number>. <minor version number>-[build number]

2. Major version number: set during project initiation, which remains unchanged throughout the project development process.

2. Version Number: set during project initiation and remains unchanged throughout the project development process.

2. Minor version number: set during project initiation and remains unchanged throughout the project development process

2. Release number: build number. It is set before the internal test starts. The initial value is 0. Each time a small change is made, the release number is + 1.

The general format of the version number is 1.0.7-101, 2.0.0-900.

3. version specification 3.1 version number Setting Rule 3.1.1 main version number

1. Set the time: set when the product is approved

2. Set rules:

2. launch a new product. The main version number is 1.

2. The product architecture has changed. The main version number is + 1.

2. major modifications are made to the main components of the product (such as the order processing framework). The main version number is + 1.

2. The product's external interface protocol is changed. The main version number is + 1.

3.1.2 minor version number

1. Set the time: set when the product is approved

2. Set rules:

2. launch a new product. The minor version number is 0.

2. To handle product bugs or improve existing functions/performance, make major changes to the existing function modules without adding new function modules. The minor version number is + 1.

2. To add product functions, a new function module is added to the original product. The product's main component has not been significantly modified, and the interface protocol between the product's main components has not been modified, minor version + 1

2. The product is changed to meet different user requirements, but the product's main component is not modified significantly, and the interface protocol between the product's main component is not modified. The minor version number is + 1.

2. When the primary version number is changed, the minor version number is set to 0 at the same time.

3.1.3 minor version

2. launch a new product. The minor version number is 0.

2. fix bugs or improve existing functions, but do not make major changes to the existing function modules. No new function modules are added. Minor version number + 1

2. When the minor version number is changed, the minor version number is set to 0 at the same time.

3.1.4 build no.

1. Set the time: product development is complete, before the internal test starts

2. Set rules:

2. the initial value of the release number is 0.

2. Each time a change is made during the test, the release number is + 1

3.2 version management 3.2.1 trunk

At any time, trunk contains the latest development code. The code here will work to the next major release version.

Trunk should only be used for development and will become your next important version of code. Do not add the version number and release name to trunk. You only need to ensure that trunk is in the "development mode" at any time ".

3.2.2 branches

There are several different types of branches. In the branches directory, you can create more paths for specific targets, such as the forthcoming version. Brahches can contain copies of trunk in different stages of development.

3.2.2.1 release branches

When the trunk reaches the release preparation stage (or you want to freeze the addition of new features), you should create a release branches. Release branches is only a copy of the current trunk.

This branches can be checked out separately, or you can start projects of the branches and later versions. You can also use this branch to fix bugs during testing. This method ensures that trunk continues development without being disturbed by the release of a specific version. Therefore, when you prepare to release a new version, the new feature of trunk will not be affected.

3.2.2.2 bug fix branches

The branch can also be used to handle serious bugs found in trunk or release branches. These bugs are complex and cannot be fixed at one commit. Therefore, to focus on correcting this error, you should create a new branch for this problem. This will not affect the continuation of trunk and release branches, and will not interfere with the fixing of this bug because of the discovery of new bugs and tests.

3.2.2.3 Experimental Branches

Sometimes you want to introduce a new technology into a project. But does not want to affect the entire project. For example, you want to change the web application from spring3x to spring4x. How long does it take? During this period, does trunk stop using it? Until all the conversions to spring are completed.

Spring4x may change the program greatly, so you should create an experiment branch. In this way, changes can be made in the branch. If the application fails and the current application is not affected, the experiment branch can be discarded. If it succeeds, it is easy to merge it into the trunk.

3.2.3 tags

Tags is used to back up code. It is usually readonly and is not used for development. It is only used to mark the code status.

3.2.3.1 1.3.1 release tags

The code of the release point marked by release tags. The release tag is always a copy of the corresponding release branch. Release tag naming rules: Version Number + "release" suffix.

4. SVN usage specification 4.1 is updated first and then submitted

The SVN update principle is to be updated at any time and submitted at any time. When a small feature is completed, it can be compiled and tested by itself, and then submitted with caution.

If someone else changes the svn file during the modification, the commit may fail. If others change the same file, the file will be merged automatically during update. If the modified row is the same, a conflict will occur during the merge, in this case, you need to contact the previous developers and negotiate with them to resolve the conflict. After the conflict is resolved, You need to test together to ensure that the program will not affect other functions after the conflict is resolved.

Pay attention to the list of updated files during the update process. If an update is generated during the submission process, you also need to re-compile and complete some necessary tests before submitting. In this way, you can understand which files have been modified by others, and avoid code errors caused by SVN merge errors.

More than 4.2 submissions

The interval of each submission is as short as possible. It is best to work on development within several hours. For example, when you change the UI, you can submit the UI once every time you modify or design the UI. When developing a function module, you can submit each time you test a small-Detail function. When modifying a bug, you can modify a bug and confirm that the bug has been modified, it will be submitted once. If you advocate multiple submissions, you can add insurance for the code.

4.3 do not submit code that cannot be compiled

Before submitting the code, make sure that the code can be locally compiled. When preparing the project work area, the project manager must ensure that the development team members can compile the code in a unified environment after checking out the code.

4.4 clear notes must be written for each submission

When SVN is used in a project team, if empty or inaccurate annotations are submitted, other members of the project team may feel helpless and the Project Manager cannot clearly grasp the work progress, the summary of this submission cannot be clearly grasped. After an error is found, you cannot accurately locate the file that causes the error. Therefore, when submitting a job, you must enter a clear description to briefly describe the information of the submitted file, let other members of the project team understand your modifications without looking at the code in detail after seeing the annotations.

4.5 do not submit files automatically generated locally.

For example, the. classpath file in eclipse, the thumbnail thumbs. DB generated by windows, the temporary file. OBJ and. Class generated by project compilation, and so on. If this configuration is not configured in the project to forcibly prohibit the submission of such files, do not submit such files. After submitting such a file, someone else may conflict with the local environment after the update, thus affecting everyone's work.

4.6 do not submit code that you do not understand

After the code is submitted to SVN, your code will be shared by the project members. If you submit code that you do not understand, you cannot understand it, and others cannot understand it. If you encounter problems in the future, it will become a risk of project quality. Therefore, before introducing any third-party code, make sure you have a clear understanding of this Code.

4.7 use the lock function with caution

Use the locked feature with caution in the project. After you lock a file, others cannot modify and submit the file. Although this can reduce the incidence of conflict, however, it may affect the work of other personnel in the project team. Locking is applicable only when you edit files that cannot be merged (such as instance files and Flash files.

5. directory structure

 

 

 

Software Version Control Specification