# HG changeset patch
# User Oleksandr Gavenko <gavenkoa@gmail.com>
# Date 1322436731 -7200
# Node ID 91e7ec70a38e4a6f3349f99057869f20aa8acd1f
# Parent  e1a7f189657101d42a9ca69bd746bbb39c68c58d
Format or protocol compatibility.

diff -r e1a7f1896571 -r 91e7ec70a38e devel-versioning.rst
--- a/devel-versioning.rst	Mon Nov 28 01:11:03 2011 +0200
+++ b/devel-versioning.rst	Mon Nov 28 01:32:11 2011 +0200
@@ -346,6 +346,9 @@
 Forms of compatibility.
 =======================
 
+Source/binary compatibility.
+----------------------------
+
 Runtime or binary compatibility mean that binary can be swaped with another
 version without breaking normal program work.
 
@@ -359,11 +362,23 @@
  * Adding new method to abstract class take binary compatibility but break
    compilation (unimplement method error).
 
-File format compatibility.
+Format or protocol compatibility.
+---------------------------------
+
+File format or protocol backward compatibility mean that new program can use old
+format or protocol.
+
+In order to do that file format or protocol MUST store or provide some
+versioning information. Usually this done by:
 
-Protocol compatibility.
+ * Separate versioning field in data.
+ * New prefix or name in data.
+ * List of feature requirements, supported algorighm, etc.
 
+It is essential make code that detect unknown or possibly new format or protocol
+and stop working with them to avoid user data corruption.
 
+Forward compati
 
 Reference.
 ==========