=================

 Version format.

=================

.. contents::

Feature set versioning.

=======================

Feature set versioning pretend to show how serious changes made according to

feature availability and how compatible these versions.

Marketing versioning.

=====================

Marketing versioning schema used for marketing, advertising purpose. It is

usually inconsistent and can changed over the time.

Examples of marketing version schema:

 * Years.

 * Ancient gods.

 * Star/satellite/galactic names.

Look thread for GDB:

  http://www.cygwin.com/ml/gdb/2007-07/msg00061.html

There discussed:

 * Is it essential to update major version if significant change made for

   licence? Answer: NO!

   GPLv3 is a big deal spread out over the whole GNU project, but not a big deal

   for GDB in particular.

 * Is it right follow date version schema regardless major changes? Answer: NO!

   Many OS distribution encode year in versions but versions does not present

   featureset but package set instead.

Year as version name.

---------------------

If year used as version some people can decide that 2005 is too old and broken

if it used in 2007. So companies release product by leading year number. So in

2007 they release 2008 version.

Version name components.

========================

 * major

 * minor

 * patch (patchlevel), micro

 * rev (revision)

 * build

 * date

::

  major.minor.rev

  major.minor.rev.build

  major.current.age

Major version component.

------------------------

Major number change means that the new version is incompatible with the old one

and any dependent of the prior version will require code changes to upgrade to

the new package.

Minor version component.

------------------------

Minor number change means that the new version is backward compatible with the

previous version but has significant enhancements over the previous version.

Revision, micro, bugfix version component.

------------------------------------------

Revision number is updated whenever a bugfix is applied to the build such that

it doesn't bring a compatibility change or introduce newer features.

Milestone markers.

------------------

 * a (alpha) means new development is complete and code checkins are frozen.

   Alpha builds should work well enough to be testable.

 * b (beta) means most severe bugs are fixed and end users can start trying the

   release.

 * rc (release candidate) are believed to meet all of the criteria for release

   and can be installed on test instances of production systems.

Release build version data.

===========================

 * Build number.

 * Build date.

 * Build version.

 * Branch-tag used.

 * Overnight build (Y/N).

 * QA tested (Y/N).

 * QA test results (Pass/Fail).

 * Location of full logs.

Version ordering formula.

=========================

Strongly recommend:

 * Numbers are not decimal fractions. They are integers separated by delimiters.

 * Only offically released versions of the program get version numbers.

   Development snapshots don't. Nor do test releases.

 * If the last component is zero, it may be omitted. Do not distinguish version

   X.Y from version X.Y.0.

 * Avoid using anything other than numbers in version numbers.

Debian version ordering formula.

--------------------------------

TODO

Semver version ordering formula.

--------------------------------

if (A.major != B.major) return A.major > B.major;

if (A.minor != B.minor) return A.minor > B.minor;

if (A.patch != B.patch) return A.patch > B.patch;

if (A.special == B.special) return 0;

if (A.special == "") return 1;

if (B.special == "") return -1;

return A.special > B.special;

**NOTE** Accoding to this definition 1.0.1rc1 < 1.0.1rc10 < 1.0.1rc2 which is

non meaningful.

Odd/even numbering.

-------------------

Who use:

  GLib GTK+ Gimp GNOME Kaffe

Compatibility formula.

======================

Assume that app linked with new version of lib. Thus::

  is_compatible_with_old(old, new) {

    if (old.major != new.major) return 0;

    if (old.minor > new.minor) return 0;

    return 1;

  }

Assume that app linked with old version of lib. Thus::

  is_compatible_with_new(old, new) {

    if (old.major != new.major) return 0;

    return 1;

  }

Reference.

==========

  https://developer.mozilla.org/en/toolkit_version_format

                Toolkit version format

  http://apr.apache.org/versioning.html

                APR's Version Numbering

  http://semver.org/

                Semantic Versioning