Version numbering basics? [closed]

Answer 1

I've used

Major.Minor.Release.Build 1.02.4.15

and also

Year.Month.Date

2009.12.10

but anything that allows you to individually track releases would work. As long as you're consistent.

Answer 2

I've always used (rewrite).(feature added).(bug fix).

But set your own rules and make them public so your users understand them.

Answer 3

After reading a lot of articles/QAs/FAQs/books I become to think that [MAJOR].[MINOR].[REV] is most useful versioning schema to describe compatibility between project version (versioning schema for developer, does not for marketing).

MAJOR changes is backward incompatible and require changing project name, path to files, GUIDs, etc.

MINOR changes is backward compatible. Mark introduction of new features.

REV for security/bug fixes. Backward and forward compatible.

This versioning schema inspired by libtool versioning semantics and by articles:

http://www106.pair.com/rhp/parallel.html

NOTE: I also recommend provide build/date/custom/quality as additional info (build number, build date, customer name, release quality):

Hello app v2.6.34 for National bank, 2011-05-03, beta, build 23545

But this info is not versioning info!!

Answer 4

When developing software libraries, I recommend using the version number to communicate the level of source and binary compatibility between two releases.

Since you're developing a web application, a two part version number is probably sufficient. The first part is for new functionality and the second is for fixes.

Answer 5

A lot of free software uses a three point system: X.Y.Z where

• X is for compatibility breaking releases.
• Y is for other releases, with even numbers being stable and odd numbers being unstable.
• Z is for fixes.

This way version 0.28.1 is a stable release with one fix and 2.9.0 is an alpha release with zero fixes.

Some people also have fun developing their own schemes. E.g. Tex which by each release approxed Pi, with version numbers: 3, 3.1, 3.14, etc.