Add a migration note about the organization of the extension modules.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxPython/Phoenix/trunk@71019 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775

docs/MigrationGuide.txt

@@ -203,3 +203,27 @@ compatibility alias exists so using wx.PyAssertionError will still work, but
 you should migrate those uses to wx.wxAssertionError if possible.
 
 
+
+
+The 'wx' namespace and submodules reorganized
+---------------------------------------------
+
+Some reorganization of what classes and functions goes in which internal wx
+extension module has been done. In Classic the organization of the extension
+modules was somewhat haphazard and caotic. For example there were 5 separate
+modules whose contents were loaded into the main "wx" package namespace and
+several others that needed to be imported separately. However since there was
+not much organization of the core the C++ wxadv and wxhtml DLLs would need to
+be distributed with any applications built with a bundling tool even if the
+application did not use any of those classes.
+
+For Phoenix the location of the wrapper code for the classes and functions
+will attempt to follow the same organization that wxWidgets uses for putting
+those same classes and functions into DLLs or shared libraries. This means
+that some things that were formerly in the core wx package namespace are no
+longer there. They will have to be used by importing a wx sumbodule. Most of
+them will be in the wx.adv module. Once nice advantage of doing this is that
+if your application is not using any of these lesser used classes then you
+will not have to bundle the new modules (nor the associated wx DLLs) with
+your application when you use py2exe or other executable builder.
+