diff --git a/CHANGES.current b/CHANGES.current
index 17574c80741..d0ab95a5eb0 100644
--- a/CHANGES.current
+++ b/CHANGES.current
@@ -16,10 +16,29 @@ Version 3.0.10 (in progress)
             (assuming bar.foo was the main module). Every place _foo is imported now first tries
             it from the package where foo was found and if that fails tries _foo as a global module.
 
-            2) The separate block of python code that injected code to pull in the attributes
+            2) The separate block of Python code that injected code to pull in the attributes
             from _foo when -builtin is used made use of the -py3 switch to either do
             'from ._foo import *' or "from _foo import *". This block of code no longer does this
-            and instead checks the python version at runtime to switch between the two syntaxes.
+            and instead checks the Python version at runtime to switch between the two syntaxes.
+
+            In summary, swig-3.0.10 has been modified to ease the creation of wrapper modules
+            that can be fully made part of a Python package.  SWIG no longer
+            assumes the dynamically linked C module is a global module.
+            The dynamic module can now be placed into either the same package as the pure Python
+            module or as a global module.  Both locations are used by the Python wrapper to
+            locate the C module.
+
+            However, this could cause a backwards incompatibility with some code
+            that was relying on the ability of "from package import _module" to
+            pull attributes out of the package directly.  If your code populates a
+            module (which is also a package) with attributes that are SWIG
+            generated modules which were not loaded in a conventional way,
+            swig-3.0.8 and earlier may have worked due to 'from package import
+            _module' bypassing a real import and pulling your module in as an
+            attribute. This will no longer work.  Since this is not a common (or
+            even recommended) practice, most folk should not be affected.
+
+            *** POTENTIAL INCOMPATIBILITY ***
 
 2016-05-31: wsfulton
             Fix #690 - Smart pointer to %ignored class doesn't expose inherited methods.