--- a/devel-versioning.rst	Fri Sep 23 12:46:18 2011 +0300
+++ b/devel-versioning.rst	Fri Sep 23 17:33:55 2011 +0300
@@ -3,6 +3,91 @@
 =================
 .. 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.
 ===========================
 
@@ -15,8 +100,26 @@
  * QA test results (Pass/Fail).
  * Location of full logs.
 
-Order formula.
-==============
+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;
@@ -29,6 +132,13 @@
 **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.
 ======================