diff --git a/ChangeLog b/ChangeLog
index dedf9c7a..2ac3efec 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,11 +1,3 @@
-IMPORTANT: the historic distinction between MARS Light and the future
-MARS Full has been dropped. Now all versions are simply called "mars".
-
-Old tagnames light* will remain valid, but newer names will follow the
-convention s/light/mars/g (this means that the old version number counting
-will be continued, only the "light" is substituted).
-
-
 Meaning of stable tagnames
 --------------------------
 
@@ -41,9 +33,9 @@ Release Conventions / Branches / Tagnames
 		 This branch is operational for several years on
 		 several thousands of servers, and several petabytes
 		 of data.
-		 - Unstable tagnames: light0.1abeta%d (obsolete)
 		 - Stable branch: mars0.1a.y
 		 - Stable tagnames: mars0.1astable%02d
+		 - Historic tagnames: light0.1abeta%d (obsolete)
 
 	mars1.0 series (planned):
 		 - Replace symlink tree by transactional status files
@@ -65,8 +57,12 @@ Release Conventions / Branches / Tagnames
 	  - Heavily tested. Has to obey an HA SLA of 99.98% end-to-end,
 	    including network outages and HumanError(tm) at 1&1 Ionos
 	    ShaHoLin. Thus the _component_ SLA of MARS must be much better.
+
+	  - New features may be introduced, but are off by default.
+
 	  - There is always an upgrade path. Simply install the new
 	    version, obeying the below compatibility rules.
+
 	  - Rolling upgrades (temporarily different MARS kernel module
 	    versions at primary vs secondary side) are supported.
 	    Typically, do "rmmod mars; modprobe mars" at the secondary
@@ -77,7 +73,9 @@ Release Conventions / Branches / Tagnames
 	    I am putting high effort into maintaining rolling upgrades
 	    of kernel modules. The network protocols are designed to
 	    support this.
+
 	-   COMPATIBILITY RULES:
+
 	    Ensure that $marsadm_version >= $module_version.
 	    This is the safe side of your update strategy.
 	    Update marsadm first, before updating the kernel module.
@@ -102,26 +100,35 @@ Release Conventions / Branches / Tagnames
 	    the gap is a small $epsilon. But I cannot guarantee in general.
 	    If you want to violate the above rule, you must test the
 	    combination yourself.
+
 	  - Best practice in bigger installations: first test your upgrade
 	    or downgrade at some test clusters first.
 	    If you have a separate pre-live stage, it definitely is
 	    your friend.
+
 	  - As long as $marsadm_version + $epsilon >= $module_version
 	    remains true (at least "approximately") and has been tested
 	    in pre-live, marsadm may be upgraded and downgraded
 	    independently from kernel, and during operations
 	    (best via your favorite package manager).
 	    Of course, no magic will happen: newer features are only
-	    available when newer versions of both the userspace tool and
+	    available when newer versions of _both_ the userspace tool and
 	    the kernel modules are installed.
+
 	  - Please check this ChangeLog for any upgrade / downgrade
 	    incompatibility bugs. In case they are detected, they will
 	    be fixed. But I cannot retrospectivly change already released
 	    versions and their bugs. Fixes are only possible in newer
 	    versions.
+
 	  - Downgrade is possible *inside* of the same stable branch
-	    series.
-	  - Downgrade to _prior_ *stable* branches may be restricted,
+	    series, at least over about 20 minor releases. I cannot test
+	    all possible O(n^2) downgrade combinations. Thus be careful when
+	    downgrading over high version distances (which should not be
+	    done anyway unless you have some very well-thought reasons).
+
+	  - Downgrade to _prior_ *stable* branches, or over very big differences
+	    in minor version number, may be restricted,
 	    or may require some extaordinary actions.
 	    Please read this ChangeLog for details.
 
@@ -132,6 +139,10 @@ Release Conventions / Branches / Tagnames
 	Only if you actually activate it, and if you really need to
 	downgrade beyond that old version, you have to obey the
 	downgrade instructions documented below.
+	However, don't rely on this. Somewhen after many releases, and after
+	its stability has been proven at 1&1 Inonos ShaHoLin over a long time,
+	the new feature may be auto-activated, so that downgrade should remain
+	possible, but may then require some manual actions.
 
 -----------------------------------
 Changelog for series 0.1a:
@@ -2090,3 +2101,12 @@ Release Policy / Software Lifecycle
 -----------------------------------
 
 	New source releases are simply announced by appearance of git tags.
+
+--------------
+
+HISTORIC FOOTNOTE: the historic distinction between MARS Light and the future
+MARS Full has been dropped. All versions are simply called "mars".
+
+Old tagnames light* will remain valid, but newer names will follow the
+convention s/light/mars/g (this means that the old version number counting
+will be continued, only the "light" is substituted).