Updating extension guidelines v2

CHANGES

@@ -66,6 +66,8 @@ Version 1.0
 - Don't leak exception info of already catched exceptions to context teardown
   handlers (pull request ``#1393``).
 - Allow custom Jinja environment subclasses (pull request ``#1422``).
+- Updated extension dev guidelines.
+
 
 Version 0.10.2
 --------------

docs/extensiondev.rst

@@ -48,7 +48,7 @@ that people can easily install the development version into their
 virtualenv without having to download the library by hand.
 
 Flask extensions must be licensed under a BSD, MIT or more liberal license
-to be able to be enlisted in the Flask Extension Registry.  Keep in mind
+in order to be listed in the Flask Extension Registry.  Keep in mind
 that the Flask Extension Registry is a moderated place and libraries will
 be reviewed upfront if they behave as required.
 
@@ -154,10 +154,10 @@ What to use depends on what you have in mind.  For the SQLite 3 extension
 we will use the class-based approach because it will provide users with an
 object that handles opening and closing database connections.
 
-What's important about classes is that they encourage to be shared around
-on module level.  In that case, the object itself must not under any
+When designing your classes, it's important to make them easily reusable
+at the module level. This means the object itself must not under any
 circumstances store any application specific state and must be shareable
-between different application.
+between different applications.
 
 The Extension Code
 ------------------
@@ -334,10 +334,10 @@ development.  If you want to learn more, it's a very good idea to check
 out existing extensions on the `Flask Extension Registry`_.  If you feel
 lost there is still the `mailinglist`_ and the `IRC channel`_ to get some
 ideas for nice looking APIs.  Especially if you do something nobody before
-you did, it might be a very good idea to get some more input.  This not
-only to get an idea about what people might want to have from an
-extension, but also to avoid having multiple developers working on pretty
-much the same side by side.
+you did, it might be a very good idea to get some more input.  This not only
+generates useful feedback on what people might want from an extension, but
+also avoids having multiple developers working in isolation on pretty much the
+same problem.
 
 Remember: good API design is hard, so introduce your project on the
 mailinglist, and let other developers give you a helping hand with
@@ -355,43 +355,37 @@ new releases.  These approved extensions are listed on the `Flask
 Extension Registry`_ and marked appropriately.  If you want your own
 extension to be approved you have to follow these guidelines:
 
-0.  An approved Flask extension requires a maintainer. In the event an
-    extension author would like to move beyond the project, the project should
-    find a new maintainer including full source hosting transition and PyPI
-    access.  If no maintainer is available, give access to the Flask core team.
-1.  An approved Flask extension must provide exactly one package or module
-    named ``flask_extensionname``.  They might also reside inside a
-    ``flaskext`` namespace packages though this is discouraged now.
-2.  It must ship a testing suite that can either be invoked with ``make test``
-    or ``python setup.py test``.  For test suites invoked with ``make
-    test`` the extension has to ensure that all dependencies for the test
-    are installed automatically.  If tests are invoked with ``python setup.py
-    test``, test dependencies can be specified in the :file:`setup.py` file.  The
-    test suite also has to be part of the distribution.
-3.  APIs of approved extensions will be checked for the following
-    characteristics:
-
-    -   an approved extension has to support multiple applications
-        running in the same Python process.
-    -   it must be possible to use the factory pattern for creating
-        applications.
-
-4.  The license must be BSD/MIT/WTFPL licensed.
-5.  The naming scheme for official extensions is *Flask-ExtensionName* or
-    *ExtensionName-Flask*.
-6.  Approved extensions must define all their dependencies in the
-    :file:`setup.py` file unless a dependency cannot be met because it is not
-    available on PyPI.
-7.  The extension must have documentation that uses one of the two Flask
-    themes for Sphinx documentation.
-8.  The setup.py description (and thus the PyPI description) has to
-    link to the documentation, website (if there is one) and there
-    must be a link to automatically install the development version
-    (``PackageName==dev``).
-9.  The ``zip_safe`` flag in the setup script must be set to ``False``,
-    even if the extension would be safe for zipping.
-10. An extension currently has to support Python 2.6 as well as
-    Python 2.7
+0. An approved Flask extension requires a maintainer. In the event an
+   extension author would like to move beyond the project, the project should
+   find a new maintainer including full source hosting transition and PyPI
+   access.  If no maintainer is available, give access to the Flask core team.
+1. An approved Flask extension must provide exactly one package or module
+   named ``flask_extensionname``.
+2. It must ship a testing suite that can either be invoked with ``make test``
+   or ``python setup.py test``.  For test suites invoked with ``make
+   test`` the extension has to ensure that all dependencies for the test
+   are installed automatically.  If tests are invoked with ``python setup.py
+   test``, test dependencies can be specified in the `setup.py` file.  The
+   test suite also has to be part of the distribution.
+3. APIs of approved extensions will be checked for the following
+   characteristics:
+
+   -   an approved extension has to support multiple applications
+       running in the same Python process.
+   -   it must be possible to use the factory pattern for creating
+       applications.
+
+4. The extension must be BSD/MIT/WTFPL licensed.
+5. The naming scheme for official extensions is *Flask-ExtensionName* or
+   *ExtensionName-Flask*.
+6. Approved extensions must define all their dependencies in the
+   `setup.py` file unless a dependency cannot be met because it is not
+   available on PyPI.
+7. The extension must have documentation that uses one of the two Flask
+   themes for Sphinx documentation.
+8. The ``zip_safe`` flag in the setup script must be set to ``False``,
+   even if the extension would be safe for zipping.
+9. An extension currently has to support Python 2.7, Python 3.3 and higher.
 
 
 .. _ext-import-transition:
@@ -410,8 +404,8 @@ deprecated ``flaskext.foo``.  Flask 0.8 introduces a redirect import
 system that lets uses import from ``flask.ext.foo`` and it will try
 ``flask_foo`` first and if that fails ``flaskext.foo``.
 
-Flask extensions should urge users to import from ``flask.ext.foo``
-instead of ``flask_foo`` or ``flaskext_foo`` so that extensions can
+Flask extensions should urge users to import from ``flask_foo``
+instead of ``flask.ext.foo`` or ``flaskext_foo`` so that extensions can
 transition to the new package name without affecting users.