开发者

What every digit means in software version (1.7.1.0, for example)?

开发者 https://www.devze.com 2022-12-29 19:25 出处:网络
What could every digit mean in software开发者_运维问答 version? (for example, 1.7.1.0) How do you numerate your versions?

What could every digit mean in software开发者_运维问答 version? (for example, 1.7.1.0) How do you numerate your versions?

Thank you.


It differs from vendor to vendor really. Most commonly, they are (in order):

  • Major release number
  • Minor release number
  • Maintenance release number (bugfixes only)
  • If used at all: build number (or source control revision number)

1.7.1.0 would this be the first maintenance release to the 1.7 version of the product.

Even defining what the difference between a major and minor release is, is difficult. Major releases normally include significant new features. Or the vendor just wants people to pay for the product again. Minor releases may include fixes and new features, but usually nothing ground breaking.

Some companies use the minor release bit to differentiate between alpha / beta releases and final releases. Odd numbers being pre-releases and even numbers being finals. 1.7 would be a beta of an upcoming 1.8 release. This habit is becoming less and less common though.

Build numbers increment with every release, no matter how minor the changes might be. It is automatically incremented by the build process, every time it runs. Many builds are never see publicly released, but they can help in managing the life cycle of the software, by making it easy for QA to uniquely identify a version of the software.


Normally these are <Major.Minor.Revision.Build>.

Where:

  • Major is a major update to the software
  • Minor is a small update to the software
  • Revision is any change made (bug fixes, small updates)
  • Build number (normally an auto increment if used)

In your example (1.7.1.0):

  • Major version 1
  • Had 7 minor updates
  • First revision/bugfix
  • No build number


Every projects chooses its own convention. As others have pointed out, one common convention is "Major.Minor.Revision.Build"

A couple of my favorites are:

Ubuntu versions are "Year.Month". For example, 10.04 was released in April 2010.

TeX versions are theoretically only bux-fixes forevermore, so their versions are asymptotically approaching pi (e.g. 3.1415926)


Another method widely used is having an incremental build number. Without any correlation to so called "version".

"Version" is more interesting for consumers wanting to know this is a new product, hence you just give every release a name.

But for internal uses and easy reference of product and his tested\source controlled version, a simple incrementing build number might be more convenient.


It depends. Here is information on Microsoft Version Numbers http://en.wikipedia.org/wiki/Microsoft_Version_Number

We have used the last digit as build numbers for our applications.

0

精彩评论

暂无评论...
验证码 换一张
取 消