1.7.txt 22 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531
  1. ============================================
  2. Django 1.7 release notes - UNDER DEVELOPMENT
  3. ============================================
  4. Welcome to Django 1.7!
  5. These release notes cover the `new features`_, as well as some `backwards
  6. incompatible changes`_ you'll want to be aware of when upgrading from Django
  7. 1.6 or older versions. We've also dropped some features, which are detailed in
  8. :doc:`our deprecation plan </internals/deprecation>`, and we've `begun the
  9. deprecation process for some features`_.
  10. .. _`new features`: `What's new in Django 1.7`_
  11. .. _`backwards incompatible changes`: `Backwards incompatible changes in 1.7`_
  12. .. _`begun the deprecation process for some features`: `Features deprecated in 1.7`_
  13. Python compatibility
  14. ====================
  15. Django 1.7 requires Python 2.7 or above, though we **highly recommend**
  16. the latest minor release. Support for Python 2.6 has been dropped.
  17. This change should affect only a small number of Django users, as most
  18. operating-system vendors today are shipping Python 2.7 or newer as their default
  19. version. If you're still using Python 2.6, however, you'll need to stick to
  20. Django 1.6 until you can upgrade your Python version. Per :doc:`our support
  21. policy </internals/release-process>`, Django 1.6 will continue to receive
  22. security support until the release of Django 1.8.
  23. What's new in Django 1.7
  24. ========================
  25. Schema migrations
  26. ~~~~~~~~~~~~~~~~~
  27. Django now has built-in support for schema migrations. It allows models
  28. to be updated, changed, and deleted by creating migration files that represent
  29. the model changes and which can be run on any development, staging or production
  30. database.
  31. Migrations are covered in :doc:`their own documentation</topics/migrations>`,
  32. but a few of the key features are:
  33. * ``syncdb`` has been deprecated and replaced by ``migrate``. Don't worry -
  34. calls to ``syncdb`` will still work as before.
  35. * A new ``makemigrations`` command provides an easy way to autodetect changes
  36. to your models and make migrations for them.
  37. * :data:`~django.db.models.signals.pre_syncdb` and
  38. :data:`~django.db.models.signals.post_syncdb` have been renamed to
  39. :data:`~django.db.models.signals.pre_migrate` and
  40. :data:`~django.db.models.signals.post_migrate` respectively. The
  41. ``create_models``/``created_models`` argument has also been deprecated.
  42. * The ``allow_syncdb`` method on database routers is now called ``allow_migrate``,
  43. but still performs the same function. Routers with ``allow_syncdb`` methods
  44. will still work, but that method name is deprecated and you should change
  45. it as soon as possible (nothing more than renaming is required).
  46. New method on Field subclasses
  47. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  48. To help power both schema migrations and composite keys, the :class:`~django.db.models.Field` API now
  49. has a new required method: ``deconstruct()``.
  50. This method takes no arguments, and returns a tuple of four items:
  51. * ``name``: The field's attribute name on its parent model, or None if it is not part of a model
  52. * ``path``: A dotted, Python path to the class of this field, including the class name.
  53. * ``args``: Positional arguments, as a list
  54. * ``kwargs``: Keyword arguments, as a dict
  55. These four values allow any field to be serialized into a file, as well as
  56. allowing the field to be copied safely, both essential parts of these new features.
  57. This change should not affect you unless you write custom Field subclasses;
  58. if you do, you may need to reimplement the ``deconstruct()`` method if your
  59. subclass changes the method signature of ``__init__`` in any way. If your
  60. field just inherits from a built-in Django field and doesn't override ``__init__``,
  61. no changes are necessary.
  62. If you do need to override ``deconstruct()``, a good place to start is the
  63. built-in Django fields (``django/db/models/fields/__init__.py``) as several
  64. fields, including ``DecimalField`` and ``DateField``, override it and show how
  65. to call the method on the superclass and simply add or remove extra arguments.
  66. Calling custom ``QuerySet`` methods from the ``Manager``
  67. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  68. The :meth:`QuerySet.as_manager() <django.db.models.query.QuerySet.as_manager>`
  69. class method has been added to :ref:`create Manager with QuerySet methods
  70. <create-manager-with-queryset-methods>`.
  71. Using a custom manager when traversing reverse relations
  72. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  73. It is now possible to :ref:`specify a custom manager
  74. <using-custom-reverse-manager>` when traversing a reverse relationship.
  75. Admin shortcuts support time zones
  76. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  77. The "today" and "now" shortcuts next to date and time input widgets in the
  78. admin are now operating in the :ref:`current time zone
  79. <default-current-time-zone>`. Previously, they used the browser time zone,
  80. which could result in saving the wrong value when it didn't match the current
  81. time zone on the server.
  82. In addition, the widgets now display a help message when the browser and
  83. server time zone are different, to clarify how the value inserted in the field
  84. will be interpreted.
  85. Using database cursors as context managers
  86. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  87. Prior to Python 2.7, database cursors could be used as a context manager. The
  88. specific backend's cursor defined the behavior of the context manager. The
  89. behavior of magic method lookups was changed with Python 2.7 and cursors were
  90. no longer usable as context managers.
  91. Django 1.7 allows a cursor to be used as a context manager that is a shortcut
  92. for the following, instead of backend specific behavior.
  93. .. code-block:: python
  94. c = connection.cursor()
  95. try:
  96. c.execute(...)
  97. finally:
  98. c.close()
  99. Minor features
  100. ~~~~~~~~~~~~~~
  101. :mod:`django.contrib.admin`
  102. ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  103. * You can now implement :attr:`~django.contrib.admin.AdminSite.site_header`,
  104. :attr:`~django.contrib.admin.AdminSite.site_title`, and
  105. :attr:`~django.contrib.admin.AdminSite.index_title` attributes on a custom
  106. :class:`~django.contrib.admin.AdminSite` in order to easily change the admin
  107. site's page title and header text. No more needing to override templates!
  108. * Buttons in :mod:`django.contrib.admin` now use the ``border-radius`` CSS
  109. property for rounded corners rather than GIF background images.
  110. * Some admin templates now have ``app-<app_name>`` and ``model-<model_name>``
  111. classes in their ``<body>`` tag to allow customizing the CSS per app or per
  112. model.
  113. * The admin changelist cells now have a ``field-<field_name>`` class in the
  114. HTML to enable style customizations.
  115. * The admin's search fields can now be customized per-request thanks to the new
  116. :meth:`django.contrib.admin.ModelAdmin.get_search_fields` method.
  117. * The :meth:`ModelAdmin.get_fields()
  118. <django.contrib.admin.ModelAdmin.get_fields>` method may be overridden to
  119. customize the value of :attr:`ModelAdmin.fields
  120. <django.contrib.admin.ModelAdmin.fields>`.
  121. * In addition to the existing ``admin.site.register`` syntax, you can use the
  122. new :func:`~django.contrib.admin.register` decorator to register a
  123. :class:`~django.contrib.admin.ModelAdmin`.
  124. :mod:`django.contrib.auth`
  125. ^^^^^^^^^^^^^^^^^^^^^^^^^^
  126. * Any ``**kwargs`` passed to
  127. :meth:`~django.contrib.auth.models.User.email_user()` are passed to the
  128. underlying :meth:`~django.core.mail.send_mail()` call.
  129. * The :func:`~django.contrib.auth.decorators.permission_required` decorator can
  130. take a list of permissions as well as a single permission.
  131. * You can override the new :meth:`AuthenticationForm.confirm_login_allowed()
  132. <django.contrib.auth.forms.AuthenticationForm.confirm_login_allowed>` method
  133. to more easily customize the login policy.
  134. * :func:`django.contrib.auth.views.password_reset` takes an optional
  135. ``html_email_template_name`` parameter used to send a multipart HTML email
  136. for password resets.
  137. :mod:`django.contrib.messages`
  138. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  139. * The backends for :mod:`django.contrib.messages` that use cookies, will now
  140. follow the :setting:`SESSION_COOKIE_SECURE` and
  141. :setting:`SESSION_COOKIE_HTTPONLY` settings.
  142. :mod:`django.contrib.sessions`
  143. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  144. * The ``"django.contrib.sessions.backends.cached_db"`` session backend now
  145. respects :setting:`SESSION_CACHE_ALIAS`. In previous versions, it always used
  146. the `default` cache.
  147. :mod:`django.contrib.sitemaps`
  148. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  149. * The :mod:`sitemap framework<django.contrib.sitemaps>` now makes use of
  150. :attr:`~django.contrib.sitemaps.Sitemap.lastmod` to set a ``Last-Modified``
  151. header in the response. This makes it possible for the
  152. :class:`~django.middleware.http.ConditionalGetMiddleware` to handle
  153. conditional ``GET`` requests for sitemaps which set ``lastmod``.
  154. :mod:`django.contrib.syndication`
  155. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  156. * The :class:`~django.utils.feedgenerator.Atom1Feed` syndication feed's
  157. ``updated`` element now utilizes ``updateddate`` instead of ``pubdate``,
  158. allowing the ``published`` element to be included in the feed (which
  159. relies on ``pubdate``).
  160. Email
  161. ^^^^^
  162. * :func:`~django.core.mail.send_mail` now accepts an ``html_message``
  163. parameter for sending a multipart ``text/plain`` and ``text/html`` email.
  164. File Uploads
  165. ^^^^^^^^^^^^
  166. * The new :attr:`UploadedFile.content_type_extra
  167. <django.core.files.uploadedfile.UploadedFile.content_type_extra>` attribute
  168. contains extra parameters passed to the ``content-type`` header on a file
  169. upload.
  170. * The new :setting:`FILE_UPLOAD_DIRECTORY_PERMISSIONS` setting controls
  171. the file system permissions of directories created during file upload, like
  172. :setting:`FILE_UPLOAD_PERMISSIONS` does for the files themselves.
  173. Forms
  174. ^^^^^
  175. * The ``<label>`` and ``<input>`` tags rendered by
  176. :class:`~django.forms.RadioSelect` and
  177. :class:`~django.forms.CheckboxSelectMultiple` when looping over the radio
  178. buttons or checkboxes now include ``for`` and ``id`` attributes, respectively.
  179. Each radio button or checkbox includes an ``id_for_label`` attribute to
  180. output the element's ID.
  181. * :attr:`Field.choices<django.db.models.Field.choices>` now allows you to
  182. customize the "empty choice" label by including a tuple with an empty string
  183. or ``None`` for the key and the custom label as the value. The default blank
  184. option ``"----------"`` will be omitted in this case.
  185. * :class:`~django.forms.MultiValueField` allows optional subfields by setting
  186. the ``require_all_fields`` argument to ``False``. The ``required`` attribute
  187. for each individual field will be respected, and a new ``incomplete``
  188. validation error will be raised when any required fields are empty.
  189. * The :meth:`~django.forms.Form.clean` method on a form no longer needs to
  190. return ``self.cleaned_data``. If it does return a changed dictionary then
  191. that will still be used.
  192. * :attr:`SelectDateWidget.months
  193. <django.forms.extras.widgets.SelectDateWidget.months>` can be used to
  194. customize the wording of the months displayed in the select widget.
  195. * The ``min_num`` and ``validate_min`` parameters were added to
  196. :func:`~django.forms.formsets.formset_factory` to allow validating
  197. a minimum number of submitted forms.
  198. Management Commands
  199. ^^^^^^^^^^^^^^^^^^^
  200. * The :djadminopt:`--no-color` option for ``django-admin.py`` allows you to
  201. disable the colorization of management command output.
  202. Models
  203. ^^^^^^
  204. * The :meth:`QuerySet.update_or_create()
  205. <django.db.models.query.QuerySet.update_or_create>` method was added.
  206. * The new :attr:`~django.db.models.Options.default_permissions` model
  207. ``Meta`` option allows you to customize (or disable) creation of the default
  208. add, change, and delete permissions.
  209. * :attr:`~django.db.models.Options.app_label` is no longer required for models
  210. that are defined in a ``models`` package within an app.
  211. * Explicit :class:`~django.db.models.OneToOneField` for
  212. :ref:`multi-table-inheritance` are now discovered in abstract classes.
  213. Signals
  214. ^^^^^^^
  215. * The ``enter`` argument was added to the
  216. :data:`~django.test.signals.setting_changed` signal.
  217. Templates
  218. ^^^^^^^^^
  219. * The :meth:`Context.push() <django.template.Context.push>` method now returns
  220. a context manager which automatically calls :meth:`pop()
  221. <django.template.Context.pop>` upon exiting the ``with`` statement.
  222. Additionally, :meth:`push() <django.template.Context.push>` now accepts
  223. parameters that are passed to the ``dict`` constructor used to build the new
  224. context level.
  225. * The :ttag:`widthratio` template tag now accepts an "as" parameter to capture
  226. the result in a variable.
  227. * The :ttag:`include` template tag will now also accept anything with a
  228. ``render()`` method (such as a ``Template``) as an argument. String
  229. arguments will be looked up using
  230. :func:`~django.template.loader.get_template` as always.
  231. * It is now possible to :ttag:`include` templates recursively.
  232. * Template objects now have an origin attribute set when
  233. :setting:`TEMPLATE_DEBUG` is ``True``. This allows template origins to be
  234. inspected and logged outside of the ``django.template`` infrastructure.
  235. * ``TypeError`` exceptions are not longer silenced when raised during the
  236. rendering of a template.
  237. * The following functions now accept a ``dirs`` parameter which is a list or
  238. tuple to override :setting:`TEMPLATE_DIRS`:
  239. * :func:`django.template.loader.get_template()`
  240. * :func:`django.template.loader.select_template()`
  241. * :func:`django.shortcuts.render()`
  242. * :func:`django.shortcuts.render_to_response()`
  243. * The :tfilter:`time` filter now accepts timzone-related :ref:`format
  244. specifiers <date-and-time-formatting-specifiers>` ``'e'``, ``'O'`` , ``'T'``
  245. and ``'Z'`` and is able to digest :ref:`time-zone-aware
  246. <naive_vs_aware_datetimes>` ``datetime`` instances performing the expected
  247. rendering.
  248. Tests
  249. ^^^^^
  250. * :class:`~django.test.runner.DiscoverRunner` has two new attributes,
  251. :attr:`~django.test.runner.DiscoverRunner.test_suite` and
  252. :attr:`~django.test.runner.DiscoverRunner.test_runner`, which facilitate
  253. overriding the way tests are collected and run.
  254. * The ``fetch_redirect_response`` argument was added to
  255. :meth:`~django.test.SimpleTestCase.assertRedirects`. Since the test
  256. client can't fetch externals URLs, this allows you to use ``assertRedirects``
  257. with redirects that aren't part of your Django app.
  258. Backwards incompatible changes in 1.7
  259. =====================================
  260. .. warning::
  261. In addition to the changes outlined in this section, be sure to review the
  262. :doc:`deprecation plan </internals/deprecation>` for any features that
  263. have been removed. If you haven't updated your code within the
  264. deprecation timeline for a given feature, its removal may appear as a
  265. backwards incompatible change.
  266. allow_syncdb/allow_migrate
  267. ~~~~~~~~~~~~~~~~~~~~~~~~~~
  268. While Django will still look at ``allow_syncdb`` methods even though they
  269. should be renamed to ``allow_migrate``, there is a subtle difference in which
  270. models get passed to these methods.
  271. For apps with migrations, ``allow_migrate`` will now get passed
  272. :ref:`historical models <historical-models>`, which are special versioned models
  273. without custom attributes, methods or managers. Make sure your ``allow_migrate``
  274. methods are only referring to fields or other items in ``model._meta``.
  275. pytz may be required
  276. ~~~~~~~~~~~~~~~~~~~~
  277. If your project handles datetimes before 1970 or after 2037 and Django raises
  278. a :exc:`~exceptions.ValueError` when encountering them, you will have to
  279. install pytz_. You may be affected by this problem if you use Django's time
  280. zone-related date formats or :mod:`django.contrib.syndication`.
  281. .. _pytz: https://pypi.python.org/pypi/pytz/
  282. Miscellaneous
  283. ~~~~~~~~~~~~~
  284. * The :meth:`django.core.files.uploadhandler.FileUploadHandler.new_file()`
  285. method is now passed an additional ``content_type_extra`` parameter. If you
  286. have a custom :class:`~django.core.files.uploadhandler.FileUploadHandler`
  287. that implements ``new_file()``, be sure it accepts this new parameter.
  288. * :class:`ModelFormSet<django.forms.models.BaseModelFormSet>`’s no longer
  289. delete instances when ``save(commit=False)`` is called. See
  290. :attr:`~django.forms.formsets.BaseFormSet.can_delete` for instructions on how
  291. to manually delete objects from deleted forms.
  292. * Loading empty fixtures emits a ``RuntimeWarning`` rather than raising
  293. :class:`~django.core.management.CommandError`.
  294. * :func:`django.contrib.staticfiles.views.serve` will now raise an
  295. :exc:`~django.http.Http404` exception instead of
  296. :exc:`~django.core.exceptions.ImproperlyConfigured` when :setting:`DEBUG`
  297. is ``False``. This change removes the need to conditionally add the view to
  298. your root URLconf, which in turn makes it safe to reverse by name. It also
  299. removes the ability for visitors to generate spurious HTTP 500 errors by
  300. requesting static files that don't exist or haven't been collected yet.
  301. * The :meth:`django.db.models.Model.__eq__` method is now defined in a
  302. way where instances of a proxy model and its base model are considered
  303. equal when primary keys match. Previously only instances of exact same
  304. class were considered equal on primary key match.
  305. * The :meth:`django.db.models.Model.__eq__` method has changed such that
  306. two ``Model`` instances without primary key values won't be considered
  307. equal (unless they are the same instance).
  308. * The :meth:`django.db.models.Model.__hash__` will now raise ``TypeError``
  309. when called on an instance without a primary key value. This is done to
  310. avoid mutable ``__hash__`` values in containers.
  311. * :class:`~django.db.models.AutoField` columns in SQLite databases will now be
  312. created using the ``AUTOINCREMENT`` option, which guarantees monotonic
  313. increments. This will cause primary key numbering behavior to change on
  314. SQLite, becoming consistent with most other SQL databases. This will only
  315. apply to newly created tables. If you have a database created with an older
  316. version of Django, you will need to migrate it to take advantage of this
  317. feature. For example, you could do the following:
  318. #) Use :djadmin:`dumpdata` to save your data.
  319. #) Rename the existing database file (keep it as a backup).
  320. #) Run :djadmin:`migrate` to create the updated schema.
  321. #) Use :djadmin:`loaddata` to import the fixtures you exported in (1).
  322. * ``django.contrib.auth.models.AbstractUser`` no longer defines a
  323. :meth:`~django.db.models.Model.get_absolute_url()` method. The old definition
  324. returned ``"/users/%s/" % urlquote(self.username)`` which was arbitrary
  325. since applications may or may not define such a url in ``urlpatterns``.
  326. Define a ``get_absolute_url()`` method on your own custom user object or use
  327. :setting:`ABSOLUTE_URL_OVERRIDES` if you want a URL for your user.
  328. * The static asset-serving functionality of the
  329. :class:`django.test.LiveServerTestCase` class has been simplified: Now it's
  330. only able to serve content already present in :setting:`STATIC_ROOT` when
  331. tests are run. The ability to transparently serve all the static assets
  332. (similarly to what one gets with :setting:`DEBUG = True <DEBUG>` at
  333. development-time) has been moved to a new class that lives in the
  334. ``staticfiles`` application (the one actually in charge of such feature):
  335. :class:`django.contrib.staticfiles.testing.StaticLiveServerCase`. In other
  336. words, ``LiveServerTestCase`` itself is less powerful but at the same time
  337. has less magic.
  338. Rationale behind this is removal of dependency of non-contrib code on
  339. contrib applications.
  340. * The old cache URI syntax (e.g. ``"locmem://"``) is no longer supported. It
  341. still worked, even though it was not documented or officially supported. If
  342. you're still using it, please update to the current :setting:`CACHES` syntax.
  343. Features deprecated in 1.7
  344. ==========================
  345. ``django.utils.dictconfig``/``django.utils.importlib``
  346. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  347. ``django.utils.dictconfig`` and ``django.utils.importlib`` were copies of
  348. respectively :mod:`logging.config` and :mod:`importlib` provided for Python
  349. versions prior to 2.7. They have been deprecated.
  350. ``django.utils.tzinfo``
  351. ~~~~~~~~~~~~~~~~~~~~~~~
  352. ``django.utils.tzinfo`` provided two :class:`~datetime.tzinfo` subclasses,
  353. ``LocalTimezone`` and ``FixedOffset``. They've been deprecated in favor of
  354. more correct alternatives provided by :mod:`django.utils.timezone`,
  355. :func:`django.utils.timezone.get_default_timezone` and
  356. :func:`django.utils.timezone.get_fixed_timezone`.
  357. ``django.utils.unittest``
  358. ~~~~~~~~~~~~~~~~~~~~~~~~~
  359. ``django.utils.unittest`` provided uniform access to the ``unittest2`` library
  360. on all Python versions. Since ``unittest2`` became the standard library's
  361. :mod:`unittest` module in Python 2.7, and Django 1.7 drops support for older
  362. Python versions, this module isn't useful anymore. It has been deprecated. Use
  363. :mod:`unittest` instead.
  364. ``django.utils.datastructures.SortedDict``
  365. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  366. As :class:`~collections.OrderedDict` was added to the standard library in
  367. Python 2.7, :class:`~django.utils.datastructures.SortedDict` is no longer
  368. needed and has been deprecated.
  369. Custom SQL location for models package
  370. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  371. Previously, if models were organized in a package (``myapp/models/``) rather
  372. than simply ``myapp/models.py``, Django would look for :ref:`initial SQL data
  373. <initial-sql>` in ``myapp/models/sql/``. This bug has been fixed so that Django
  374. will search ``myapp/sql/`` as documented. The old location will continue to
  375. work until Django 1.9.
  376. ``declared_fieldsets`` attribute on ``ModelAdmin``
  377. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  378. ``ModelAdmin.declared_fieldsets`` has been deprecated. Despite being a private
  379. API, it will go through a regular deprecation path. This attribute was mostly
  380. used by methods that bypassed ``ModelAdmin.get_fieldsets()`` but this was
  381. considered a bug and has been addressed.
  382. ``syncdb``
  383. ~~~~~~~~~~
  384. The ``syncdb`` command has been deprecated in favour of the new ``migrate``
  385. command. ``migrate`` takes the same arguments as ``syncdb`` used to plus a few
  386. more, so it's safe to just change the name you're calling and nothing else.
  387. ``util`` modules renamed to ``utils``
  388. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  389. The following instances of ``util.py`` in the Django codebase have been renamed
  390. to ``utils.py`` in an effort to unify all util and utils references:
  391. * ``django.contrib.admin.util``
  392. * ``django.contrib.gis.db.backends.util``
  393. * ``django.db.backends.util``
  394. * ``django.forms.util``
  395. ``get_formsets`` method on ``ModelAdmin``
  396. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  397. ``ModelAdmin.get_formsets`` has been deprecated in favor of the new
  398. :meth:`~django.contrib.admin.ModelAdmin.get_formsets_with_inlines`, in order to
  399. better handle the case of selecting showing inlines on a ``ModelAdmin``.