Software version naming specification and description of each stage

preface

A lot of developers don’t go through the iterative process of product development. They basically finish a set, go through at most one or two iterations, move to another project or leave, and then do the same thing over and over again until they leave the industry.

The developer develops a version every 3 months and locates the version1. If there is a bug, how to upgrade the version after fixing it? It may be version2, after fixing this bug, if there are still bugs, it may continue to be version3. If this goes on, before the product is launched, your version number will be very large, and it will be hard to remember which version has what functions. If the product is launched, it will be upgraded. You can imagine that after going on like this, it may reach version9999….

Naming format

Version control three common naming formats :GNU version number naming format, Windows version number naming format, and.net Framework version number naming format.

GNU style version number naming format

Minor version number [. Modified version number [. Compiled version number]] 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

Minor version number [Modified version number [. Compiled version number]] major_version_number. Minor_Version_Number[Revision_Number[.build_number]] Example: 1.21, 2.0

.NET Framework style version number naming format

Minor version number [. Compile version number [.Revision version number]] major_version_number.minor_version_number [.build_number [.revision_number]] The version number consists of two to four parts: Major, minor, internal, and Revision numbers. Major and minor version numbers are mandatory; The build number and revision number are optional, but if a revision section is defined, the build number is mandatory. All parts of the definition must be integers greater than or equal to 0.

These sections should be used according to the following conventions:

Major: Assemblies with the same name but different Major version numbers are not interchangeable. This applies, for example, to a large number of product rewrites that make backward compatibility impossible.

Minor: If the names of two assemblies are the same as the major version number, but the Minor version number is different, this indicates significant enhancement, but takes care of backward compatibility. For example, this applies to a modified version of the product or a new version that is fully backward compatible.

Build: A different Build number indicates a recompilation of the same source. This is suitable for changing processors, platforms, or compilers.

Revision: Assemblies with the same name, major, and minor version numbers but different Revision numbers should be fully interchangeable. This applies to fixing security holes in previously released assemblies.

Subsequent versions of an assembly that differ only in internal or revision numbers are considered Hotfix updates to previous versions.

Because the current market software is basically mobile terminal, so this is mainly introduced GNU style.

Description of software version phases

• Base version: this version indicates that the software is just a fake page link, usually including all the functions and page layout, but the functions in the page are not fully implemented, just as an infrastructure of the overall site.

• Alpha: This version indicates that the software is mainly used to implement software functions at this stage and is usually only communicated among software developers. Generally speaking, this version of the software has many bugs and needs to be modified.

• Beta: This release is a big improvement over alpha, eliminating serious bugs, but there are still some bugs that need to be addressed through multiple tests. The main changes in this release are to the UI of the software.

• RC: This is a fairly mature version, with virtually no bugs causing errors, similar to the upcoming official release.

• Release: This version means “final version”. After a series of beta versions of the previous version, there is a final Release, which is the final Release for users. This version is sometimes called the Standard edition. In general, Release does not appear as a word on the software cover, but instead as a symbol (R).

Version naming conventions

The software version number consists of four parts:

• The first part is the major version number
• The second part is the sub-version number
• The third part is the phase version number
• The fourth part is the date version number plus the Greek letter version number
  

  

Version number Change rule

• The major version number is changedWhen there are major changes in functional modules, such as adding more modules or changing the overall architecture. This version number is modified at the project’s discretion.
• The subversion number is changedWhen certain functions are added or changed, for example, the function of permission control or custom view is added. This version number is modified at the project’s discretion.
• Phase version number changedIt is usually a Bug fix or minor change, and revisions should be released frequently at any time interval, fixing a serious Bug and releasing a revision. This version number is at the discretion of the project manager.
• Date version numberIt is used to record the current date of the modified item. Every modification to the item requires a change in the date version number. This version number is at the discretion of the developer.
• Greek alphabet version numberThis version number is used to mark the development phase of the current version of the software and needs to be changed when the software moves to another phase. This version number is modified at the project’s discretion.

Version Number Phase identifier

The name of the stage	Phase identification
Demand for control	a
The design phase	b
Coding phase	c
Unit testing	d
Unit test modification	e
Integration testing	f
Integration test modification	g
The system test	h
System test modification	i
The acceptance test	j
Acceptance test modification	k

Personal blog

Tencent Cloud Community

CSDN

Jane’s book

The public no. :