CODEWITHSUNDEEP
svnversion-controlversioning
Sam
Sam

Reputation: 439

What is the common used or category of version number name specification?

The version number of a software will be like 2.0.0.1 What is the rule of each numbers? In what situation the number will add one?

Upvotes: 2

Views: 348

Answers (3)

mathijsbrand
mathijsbrand

Reputation: 383

Semantic versioning is used very often. I would read that first. Most adopt some form of it like:

<major>.<minor>.<patch>

or 

<major>.<minor>.<patch>-<qualifier>-<build number>

A short abstract with basic rules:

Given a version number MAJOR.MINOR.PATCH, increment the:

  • MAJOR version when you make incompatible API changes,
  • MINOR version when you add functionality in a backwards-compatible manner, and
  • PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

Then - like with anything - there is discussion on some of the details. This is not math. Often a marketing department is involved with the Major version versus the Minor version. Anyhow, this page can be good to read: What version numbering scheme to use?

Upvotes: 2

skribe
skribe

Reputation: 3615

Usually there are only three numbers used Major.Minor.Revision/Patch.

Generally...

Major = When a large amount of new functionally is added, the underlying core changes enough that the previous version of the software will not be fully compatible with the output files of the new version, or something like the UI receives significant changes, etc.

Minor = When a new small feature is added, or major fixes.

Revision = When bug fixes are released, but no new features.

Upvotes: 1

John Leidegren
John Leidegren

Reputation: 60997

There's this web document called Semantic Versioning that sort of tries to standardize this but it's really never ever been one way to do this.

If you have release cycles I presume it's reasonable to increment the major/minor parts to reflect this but versioning in this sense is probably a thing of the past.

Today, I find (more often than so) that the source control mechanism is used to stamp a code base with a version number.

SO used to just have a revision number but has since employed a versioning scheme like this rev 2015.2.12.2293 the first part is obviously a date and the last figure is in all likelyhood a build number. Which is simply a incrementing integer that uniquely identifies the build you have. This requires that you have build server that builds your final version but when you do so you get the ability to track/trace everything that you produce and that's kind of why we use versions.

Another way to do this is to build the Git commit SHA-1 into the code. It will allow you to bring up the exact state that was used to build your application (assuming that everything resides in a Git repo). Though SHA-1 is a bit long for versions so you use tags or some external database to track which SHA-1 is which build number.

Upvotes: 2

Related Questions