--------

- The ``Configurator`` object now has two new methods: ``begin`` and
  ``end``.  The ``begin`` method is meant to be called before any
  "configuration" begins (e.g. before ``add_view``, et. al are
  called).  The ``end`` method is meant to be called after all
  "configuration" is complete.

  Previously, before there was imperative configuration at all (1.1
  and prior), configuration begin and end was invariably implied by
  the process of loading a ZCML file.  When a ZCML load happened, the
  threadlocal data structure containing the request and registry was
  modified before the load, and torn down after the load, making sure
  that all framework code that needed ``get_current_registry`` for the
  duration of the ZCML load was satisfied.

  Some API methods called during imperative configuration, (such as
  ``Configurator.add_view`` when a renderer is involved) end up for
  historical reasons calling ``get_current_registry``.  However, in
  1.2a5 and below, the Configurator supplied no functionality that
  allowed people to make sure that ``get_current_registry`` returned
  the registry implied by the configurator being used.  ``begin`` now
  serves this purpose.  Inversely, ``end`` pops the thread local
  stack, undoing the actions of ``begin``.

  We make this boundary explicit to reduce the potential for confusion
  when the configurator is used in different circumstances (e.g. in
  unit tests and app code vs. just in initial app setup).

  Existing code written for 1.2a1-1.2a5 which does not call ``begin``
  or ``end`` continues to work in the same manner it did before.  It
  is however suggested that this code be changed to call ``begin`` and
  ``end`` to reduce the potential for confusion in the future.

- All ``paster`` templates which generate an application skeleton now
  make use of the new ``begin`` and ``end`` methods of the
  Configurator they use in their respective copies of ``run.py`` and
  ``tests.py``.

Documentation
-------------

- All documentation that makes use of a ``Configurator`` object to do
  application setup and test setup now makes use of the new ``begin``
  and ``end`` methods of the configurator.

Bug Fixes
---------

- When a ``repoze.bfg.exceptions.NotFound`` or
  ``repoze.bfg.exceptions.Forbidden`` *class* (as opposed to instance)
  was raised as an exception within a root factory (or route root
  factory), the exception would not be caught properly by the
  ``repoze.bfg.`` Router and it would propagate to up the call stack,
  as opposed to rendering the not found view or the forbidden view as
  would have been expected.

  ``setup.py`` ``tests_require`` argument (Twill will only be
  downloaded when :mod:`repoze.bfg` ``setup.py test`` or ``setup.py
  nosetests`` is invoked).

  environment variable (``BFG_CONFIGURE_ZCML``) to name a ZCML file
  that will be used to bootstrap the application.  Previously, the
  integrator could not influence which ZCML file was used to do the
  boostrapping (only the original application developer could do so).

  - Rather than prepare the "stock" implementations of the ZCML
    directives from the ``zope.configuration`` package for use under
    :mod:`repoze.bfg`, :mod:`repoze.bfg` now makes available the
    implementations of directives from the ``repoze.zcml`` package
    (see http://static.repoze.org/zcmldocs).  As a result, the
    :mod:`repoze.bfg` package now depends on the ``repoze.zcml``
    package, and no longer depends directly on the ``zope.component``,
    ``zope.configuration``, ``zope.interface``, or ``zope.proxy``
    packages.

    The primary reason for this change is to enable us to eventually
    reduce the number of inappropriate :mod:`repoze.bfg` Zope package
    dependencies, as well as to shed features of dependent package
    directives that don't make sense for :mod:`repoze.bfg`.

    Note that currently the set of requirements necessary to use bfg
    has not changed.  This is due to inappropriate Zope package
    requirements in ``chameleon.zpt``, which will hopefully be
    remedied soon.

  - BFG applications written prior to this release which expect the
    "stock" ``zope.component`` ZCML directive implementations
    (e.g. ``adapter``, ``subscriber``, or ``utility``) to function now
    must either 1) include the ``meta.zcml`` file from
    ``zope.component`` manually (e.g. ``<include
    package="zope.component" file="meta.zcml">``) and include the
    ``zope.security`` package as an ``install_requires`` dependency or
    2) change the ZCML in their applications to use the declarations
    from `repoze.zcml <http://static.repoze.org/zcmldocs/>`_ instead
    of the stock declarations.  ``repoze.zcml`` only makes available
    the ``adapter``, ``subscriber`` and ``utility`` directives.

  - The ``http://namespaces.repoze.org/bfg`` XML namespace is now the
    default XML namespace in ZCML for paster-generated applications.

  - The copies of BFG's ``meta.zcml`` and ``configure.zcml`` were
    removed from the root of the ``repoze.bfg`` package.  In 0.3.6, a
    new package named ``repoze.bfg.includes`` was added, which
    contains the "correct" copies of these ZCML files; the ones that
    were removed were for backwards compatibility purposes.

  Other

  - The minimum requirement for ``chameleon.core`` is now 1.0b13.  The
    minimum requirement for ``chameleon.zpt`` is now 1.0b7.  The
    minimum requirement for ``chameleon.genshi`` is now 1.0b2.

    ``configure.zcml.pck`` next to the applications's "normal" 
    configuration file.  A given bfg app will usually start faster
    if it's able to read the pickle data.  It fails gracefully
    to reading the real ZCML file if it cannot read the pickle.