      use_for_related_fields = True
  
      def __init__(self, *args, **kwargs):
          warnings.warn(
              "The GeoManager class is deprecated. Simply use a normal manager "
              "once you have replaced all calls to GeoQuerySet methods by annotations.",
              RemovedInDjango20Warning, stacklevel=2
 
</s> remove If the normal plain manager class (:class:`django.db.models.Manager`) is not
appropriate for your circumstances, you can force Django to use the same class
as the default manager for your model by setting the ``use_for_related_fields``
attribute on the manager class. This is documented fully below_.
 </s> add If the normal base manager class (:class:`django.db.models.Manager`) isn't
appropriate for your circumstances, you can tell Django which class to use by
setting :attr:`Meta.base_manager_name
<django.db.models.Options.base_manager_name>`. </s> remove 
.. _manager-types:

Controlling automatic manager types
===================================

This document has already mentioned a couple of places where Django creates a
manager class for you: `default managers`_ and the "plain" manager used to
`access related objects`_. There are other places in the implementation of
Django where temporary plain managers are needed. Those automatically created
managers will normally be instances of the :class:`django.db.models.Manager`
class.

.. _default managers: manager-names_
.. _access related objects: managers-for-related-objects_

Throughout this section, we will use the term "automatic manager" to mean a
manager that Django creates for you -- either as a default manager on a model
with no managers, or to use temporarily when accessing related objects.

Sometimes this default class won't be the right choice. The default manager
may not have all the methods you need to work with your data. A custom manager
class of your own will allow you to create custom ``QuerySet`` objects to give
you the information you need.

Django provides a way for custom manager developers to say that their manager
class should be used for automatic managers whenever it is the default manager
on a model. This is done by setting the ``use_for_related_fields`` attribute on
the manager class::

    class MyManager(models.Manager):
        use_for_related_fields = True
        # ...

If this attribute is set on the *default* manager for a model (only the
default manager is considered in these situations), Django will use that class
whenever it needs to automatically create a manager for the class.  Otherwise,
it will use :class:`django.db.models.Manager`.

.. admonition:: Historical Note

    Given the purpose for which it's used, the name of this attribute
    (``use_for_related_fields``) might seem a little odd. Originally, the
    attribute only controlled the type of manager used for related field
    access, which is where the name came from. As it became clear the concept
    was more broadly useful, the name hasn't been changed. This is primarily
    so that existing code will :doc:`continue to work </misc/api-stability>` in
    future Django versions.

Writing correct managers for use in automatic manager instances
---------------------------------------------------------------

The ``use_for_related_fields`` feature is primarily for managers that need to
return a custom ``QuerySet`` subclass. In providing this functionality in your
manager, there are a couple of things to remember.

Do not filter away any results in this type of manager subclass
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

One reason an automatic manager is used is to access objects that are related
to from some other model. In those situations, Django has to be able to see
all the objects for the model it is fetching, so that *anything* which is
referred to can be retrieved.

If you override the ``get_queryset()`` method and filter out any rows, Django
will return incorrect results. Don't do that. A manager that filters results
in ``get_queryset()`` is not appropriate for use as an automatic manager.

Set ``use_for_related_fields`` when you define the class
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The ``use_for_related_fields`` attribute must be set on the manager *class*, not
on an *instance* of the class. The earlier example shows the correct way to set
it, whereas the following will not work::

    # BAD: Incorrect code
    class MyManager(models.Manager):
        # ...
        pass

    # Sets the attribute on an instance of MyManager. Django will
    # ignore this setting.
    mgr = MyManager()
    mgr.use_for_related_fields = True

    class MyModel(models.Model):
        # ...
        objects = mgr

    # End of incorrect code.

You also shouldn't change the attribute on the class object after it has been
used in a model, since the attribute's value is processed when the model class
is created and not subsequently reread. Set the attribute on the manager class
when it is first defined, as in the initial example of this section and
everything will work smoothly.
 </s> add  </s> remove .. _below: manager-types_
 </s> add Don't filter away any results in this type of manager subclass
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This manager is used to access objects that are related to from some other
model. In those situations, Django has to be able to see all the objects for
the model it is fetching, so that *anything* which is referred to can be
retrieved.

If you override the ``get_queryset()`` method and filter out any rows, Django
will return incorrect results. Don't do that. A manager that filters results
in ``get_queryset()`` is not appropriate for use as a default manager. </s> remove         manager = self.related.related_model._default_manager
        # If the related manager indicates that it should be used for
        # related fields, respect that.
        if not getattr(manager, 'use_for_related_fields', False):
            manager = self.related.related_model._base_manager
 </s> add         related_model = self.related.related_model

        if (not related_model._meta.base_manager_name and
                getattr(related_model._default_manager, 'use_for_related_fields', False)):
            if not getattr(related_model._default_manager, 'silence_use_for_related_fields_deprecation', False):
                warnings.warn(
                    "use_for_related_fields is deprecated, instead "
                    "set Meta.base_manager_name on '{}'.".format(related_model._meta.label),
                    RemovedInDjango20Warning, 2
                )
            manager = related_model._default_manager
        else:
            manager = related_model._base_manager

    # No need to bother users with the use_for_related_fields
    # deprecation for this manager which is itself deprecated.
    silence_use_for_related_fields_deprecation = True

      use_for_related_fields = True
  
    # No need to bother users with the use_for_related_fields
    # deprecation for this manager which is itself deprecated.
    silence_use_for_related_fields_deprecation = True

      def __init__(self, *args, **kwargs):
          warnings.warn(
              "The GeoManager class is deprecated. Simply use a normal manager "
              "once you have replaced all calls to GeoQuerySet methods by annotations.",
              RemovedInDjango20Warning, stacklevel=2
keep add keep keep keep keep keep
 Fixed #10506, #13793, #14891, #25201 -- Introduced new APIs to specify models' default and base managers.

This deprecates use_for_related_fields.

Old API:

class CustomManager(models.Model):
    use_for_related_fields = True

class Model(models.Model):
    custom_manager = CustomManager()

New API:

class Model(models.Model):
    custom_manager = CustomManager()

    class Meta:
        base_manager_name = 'custom_manager'

Refs #20932, #25897.

Thanks Carl Meyer for the guidance throughout this work.
Thanks Tim Graham for writing the docs. 
django/contrib/gis/db/models/manager.py