From ee11d325a426480a8549069b2d003bb8eec107f8 Mon Sep 17 00:00:00 2001 From: Aymeric Augustin Date: Sat, 18 May 2013 10:29:01 +0200 Subject: Reorganize committers list chronologically. This completes the removal of the distinction between core devs and specialists. Patch by Simon Meers. --- docs/internals/committers.txt | 187 +++++++++++++++++++++--------------------- 1 file changed, 93 insertions(+), 94 deletions(-) (limited to 'docs/internals') diff --git a/docs/internals/committers.txt b/docs/internals/committers.txt index 6b9c7df14a..131f9c0f26 100644 --- a/docs/internals/committers.txt +++ b/docs/internals/committers.txt @@ -88,6 +88,23 @@ Malcolm Tredinnick *Malcolm passed away on March 17, 2013.* +`Luke Plant`_ + At University Luke studied physics and Materials Science and also + met `Michael Meeks`_ who introduced him to Linux and Open Source, + re-igniting an interest in programming. Since then he has + contributed to a number of Open Source projects and worked + professionally as a developer. + + Luke has contributed many excellent improvements to Django, + including database-level improvements, the CSRF middleware and + many unit tests. + + Luke currently works for a church in Bradford, UK, and part-time + as a freelance developer. + +.. _luke plant: http://lukeplant.me.uk/ +.. _michael meeks: http://en.wikipedia.org/wiki/Michael_Meeks_(software) + `Russell Keith-Magee`_ Russell studied physics as an undergraduate, and studied neural networks for his PhD. His first job was with a startup in the defense industry developing @@ -102,6 +119,42 @@ Malcolm Tredinnick .. _russell keith-magee: http://cecinestpasun.com/ +`James Bennett`_ + James is Django's release manager, and also contributes to the + documentation and provide the occasional bugfix. + + James came to Web development from philosophy when he discovered + that programmers get to argue just as much while collecting much + better pay. He lives in Lawrence, Kansas and previously worked at + World Online; currently, he's part of the Web development team at + Mozilla. + + He `keeps a blog`_, and enjoys fine port and talking to his car. + +.. _james bennett: http://b-list.org/ +.. _keeps a blog: `james bennett`_ + +`Gary Wilson`_ + Gary starting contributing patches to Django in 2006 while developing Web + applications for `The University of Texas`_ (UT). Since, he has made + contributions to the email and forms systems, as well as many other + improvements and code cleanups throughout the code base. + + Gary is currently a developer and software engineering graduate student at + UT, where his dedication to spreading the ways of Python and Django never + ceases. + + Gary lives in Austin, Texas, USA. + +.. _Gary Wilson: http://thegarywilson.com/ +.. _The University of Texas: http://www.utexas.edu/ + +Matt Boersma + Matt is responsible for Django's Oracle support. + +Ian Kelly + Ian is also responsible for Django's support for Oracle. + Joseph Kocherhans Joseph was the director of lead development at EveryBlock and previously developed at the Lawrence Journal-World. He is treasurer of the `Django @@ -119,23 +172,6 @@ Joseph Kocherhans .. _django software foundation: https://www.djangoproject.com/foundation/ .. _charango: http://en.wikipedia.org/wiki/Charango -`Luke Plant`_ - At University Luke studied physics and Materials Science and also - met `Michael Meeks`_ who introduced him to Linux and Open Source, - re-igniting an interest in programming. Since then he has - contributed to a number of Open Source projects and worked - professionally as a developer. - - Luke has contributed many excellent improvements to Django, - including database-level improvements, the CSRF middleware and - many unit tests. - - Luke currently works for a church in Bradford, UK, and part-time - as a freelance developer. - -.. _luke plant: http://lukeplant.me.uk/ -.. _michael meeks: http://en.wikipedia.org/wiki/Michael_Meeks_(software) - `Brian Rosner`_ Brian is currently the tech lead at Eldarion_ managing and developing Django / Pinax_ based Web sites. He enjoys learning more about programming @@ -153,21 +189,6 @@ Joseph Kocherhans .. _django dose: http://djangodose.com/ .. _pinax: http://pinaxproject.com/ -`Gary Wilson`_ - Gary starting contributing patches to Django in 2006 while developing Web - applications for `The University of Texas`_ (UT). Since, he has made - contributions to the email and forms systems, as well as many other - improvements and code cleanups throughout the code base. - - Gary is currently a developer and software engineering graduate student at - UT, where his dedication to spreading the ways of Python and Django never - ceases. - - Gary lives in Austin, Texas, USA. - -.. _Gary Wilson: http://thegarywilson.com/ -.. _The University of Texas: http://www.utexas.edu/ - Justin Bronn Justin Bronn is a computer scientist and attorney specializing in legal topics related to intellectual property and spatial law. @@ -232,6 +253,15 @@ Karen Tracey .. _Alex Gaynor: http://alexgaynor.net .. _Rdio: http://rdio.com +`Simon Meers`_ + Simon discovered Django 0.96 during his Computer Science PhD research and + has been developing with it full-time ever since. His core code + contributions are mostly in Django's admin application. + + Simon works as a freelance developer based in Wollongong, Australia. + +.. _Simon Meers: http://simonmeers.com/ + `Andrew Godwin`_ Andrew is a freelance Python developer and tinkerer, and has been developing against Django since 2007. He graduated from Oxford University @@ -265,6 +295,18 @@ Ramiro Morales Ramiro lives in Córdoba, Argentina. +`Gabriel Hurley`_ + Gabriel has been working with Django since 2008, shortly after the 1.0 + release. Convinced by his business partner that Python and Django were the + right direction for the company, he couldn't have been more happy with the + decision. His contributions range across many areas in Django, but years of + copy-editing and an eye for detail lead him to be particularly at home + while working on Django's documentation. + + Gabriel works as a web developer in Berkeley, CA, USA. + +.. _gabriel hurley: http://strikeawe.com/ + `Chris Beaven`_ Chris has been submitting patches and suggesting crazy ideas for Django since early 2006. An advocate for community involvement and a long-term @@ -290,6 +332,13 @@ Honza Král .. _Whiskey Media: http://www.whiskeymedia.com/ +Tim Graham + When exploring Web frameworks for an independent study project in the fall + of 2008, Tim discovered Django and was lured to it by the documentation. + He enjoys contributing to the docs because they're awesome. + + Tim works as a software engineer and lives in Philadelphia, PA, USA. + `Idan Gazit`_ As a self-professed design geek, Idan was initially attracted to Django sometime between magic-removal and queryset-refactor. Formally trained @@ -439,6 +488,18 @@ Jeremy Dunck .. _Ultimate Frisbee: http://www.montrealultimate.ca .. _Reptiletech: http://www.reptiletech.com +Donald Stufft + Donald found Python and Django in 2007 while trying to find a language, + and web framework that he really enjoyed using after many years of PHP. He + fell in love with the beauty of Python and the way Django made tasks simple + and easy. His contributions to Django focus primarily on ensuring that it + is and remains a secure web framework. + + Donald currently works at `Nebula Inc`_ as a Software Engineer for their + security team and lives in the Greater Philadelphia Area. + +.. _Nebula Inc: https://www.nebula.com/ + `Daniel Lindsley`_ Pythonista since 2003, Djangonaut since 2006. Daniel started with Django just after the v0.90 release (back when ``Manipulators`` looked good) & fell @@ -453,56 +514,6 @@ Jeremy Dunck .. _`Daniel Lindsley`: http://toastdriven.com/ .. _`Amazon Web Services`: https://aws.amazon.com/ -`James Bennett`_ - James is Django's release manager, and also contributes to the - documentation and provide the occasional bugfix. - - James came to Web development from philosophy when he discovered - that programmers get to argue just as much while collecting much - better pay. He lives in Lawrence, Kansas and previously worked at - World Online; currently, he's part of the Web development team at - Mozilla. - - He `keeps a blog`_, and enjoys fine port and talking to his car. - -.. _james bennett: http://b-list.org/ -.. _keeps a blog: `james bennett`_ - -Ian Kelly - Ian is responsible for Django's support for Oracle. - -Matt Boersma - Matt is also responsible for Django's Oracle support. - -`Simon Meers`_ - Simon discovered Django 0.96 during his Computer Science PhD research and - has been developing with it full-time ever since. His core code - contributions are mostly in Django's admin application. He is also helping - to improve Django's documentation. - - Simon works as a freelance developer based in Wollongong, Australia. - -.. _simon meers: http://simonmeers.com/ - -`Gabriel Hurley`_ - Gabriel has been working with Django since 2008, shortly after the 1.0 - release. Convinced by his business partner that Python and Django were the - right direction for the company, he couldn't have been more happy with the - decision. His contributions range across many areas in Django, but years of - copy-editing and an eye for detail lead him to be particularly at home - while working on Django's documentation. - - Gabriel works as a web developer in Berkeley, CA, USA. - -.. _gabriel hurley: http://strikeawe.com/ - -Tim Graham - When exploring Web frameworks for an independent study project in the fall - of 2008, Tim discovered Django and was lured to it by the documentation. - He enjoys contributing to the docs because they're awesome. - - Tim works as a software engineer and lives in Philadelphia, PA, USA. - Marc Tamlyn Marc started life on the web using Django 1.2 back in 2010, and has never looked back. He was involved with rewriting the class based view @@ -515,18 +526,6 @@ Marc Tamlyn .. _CCBV: http://ccbv.co.uk/ .. _Incuna Ltd: http://incuna.com/ -Donald Stufft - Donald found Python and Django in 2007 while trying to find a language, - and web framework that he really enjoyed using after many years of PHP. He - fell in love with the beauty of Python and the way Django made tasks simple - and easy. His contributions to Django focus primarily on ensuring that it - is and remains a secure web framework. - - Donald currently works at `Nebula Inc`_ as a Software Engineer for their - security team and lives in the Greater Philadelphia Area. - -.. _Nebula Inc: https://www.nebula.com/ - Developers Emeritus =================== -- cgit v1.3 From bd97f7d0cb72191744552142817184e88ce8841d Mon Sep 17 00:00:00 2001 From: Łukasz Langa Date: Sat, 18 May 2013 16:10:14 +0200 Subject: Fixed #15201: Marked CACHE_MIDDLEWARE_ANONYMOUS_ONLY as deprecated --- django/middleware/cache.py | 11 ++++++----- docs/faq/admin.txt | 6 ------ docs/internals/deprecation.txt | 2 ++ docs/ref/settings.txt | 8 ++++++-- docs/releases/1.6.txt | 17 +++++++++++++++++ docs/topics/cache.txt | 12 +++--------- tests/cache/tests.py | 8 +++++--- 7 files changed, 39 insertions(+), 25 deletions(-) (limited to 'docs/internals') diff --git a/django/middleware/cache.py b/django/middleware/cache.py index 83860e15f3..e13a8c3918 100644 --- a/django/middleware/cache.py +++ b/django/middleware/cache.py @@ -29,11 +29,6 @@ More details about how the caching works: of the response's "Cache-Control" header, falling back to the CACHE_MIDDLEWARE_SECONDS setting if the section was not found. -* If CACHE_MIDDLEWARE_ANONYMOUS_ONLY is set to True, only anonymous requests - (i.e., those not made by a logged-in user) will be cached. This is a simple - and effective way of avoiding the caching of the Django admin (and any other - user-specific content). - * This middleware expects that a HEAD request is answered with the same response headers exactly like the corresponding GET request. @@ -48,6 +43,8 @@ More details about how the caching works: """ +import warnings + from django.conf import settings from django.core.cache import get_cache, DEFAULT_CACHE_ALIAS from django.utils.cache import get_cache_key, learn_cache_key, patch_response_headers, get_max_age @@ -200,5 +197,9 @@ class CacheMiddleware(UpdateCacheMiddleware, FetchFromCacheMiddleware): else: self.cache_anonymous_only = cache_anonymous_only + if self.cache_anonymous_only: + msg = "CACHE_MIDDLEWARE_ANONYMOUS_ONLY has been deprecated and will be removed in Django 1.8." + warnings.warn(msg, PendingDeprecationWarning, stacklevel=1) + self.cache = get_cache(self.cache_alias, **cache_kwargs) self.cache_timeout = self.cache.default_timeout diff --git a/docs/faq/admin.txt b/docs/faq/admin.txt index 1d9a7c7427..ec40754094 100644 --- a/docs/faq/admin.txt +++ b/docs/faq/admin.txt @@ -27,12 +27,6 @@ account has :attr:`~django.contrib.auth.models.User.is_active` and :attr:`~django.contrib.auth.models.User.is_staff` set to True. The admin site only allows access to users with those two fields both set to True. -How can I prevent the cache middleware from caching the admin site? -------------------------------------------------------------------- - -Set the :setting:`CACHE_MIDDLEWARE_ANONYMOUS_ONLY` setting to ``True``. See the -:doc:`cache documentation ` for more information. - How do I automatically set a field's value to the user who last edited the object in the admin? ----------------------------------------------------------------------------------------------- diff --git a/docs/internals/deprecation.txt b/docs/internals/deprecation.txt index 774de2a2fd..095b6d0a33 100644 --- a/docs/internals/deprecation.txt +++ b/docs/internals/deprecation.txt @@ -390,6 +390,8 @@ these changes. ``django.test.testcases.OutputChecker`` will be removed. Instead use the doctest module from the Python standard library. +* The ``CACHE_MIDDLEWARE_ANONYMOUS_ONLY`` setting will be removed. + 2.0 --- diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt index eb470cdd14..8ef59064f7 100644 --- a/docs/ref/settings.txt +++ b/docs/ref/settings.txt @@ -280,6 +280,12 @@ CACHE_MIDDLEWARE_ANONYMOUS_ONLY Default: ``False`` +.. deprecated:: 1.6 + + This setting was largely ineffective because of using cookies for sessions + and CSRF. See the :doc:`Django 1.6 release notes` for more + information. + If the value of this setting is ``True``, only anonymous requests (i.e., not those made by a logged-in user) will be cached. Otherwise, the middleware caches every page that doesn't have GET or POST parameters. @@ -287,8 +293,6 @@ caches every page that doesn't have GET or POST parameters. If you set the value of this setting to ``True``, you should make sure you've activated ``AuthenticationMiddleware``. -See :doc:`/topics/cache`. - .. setting:: CACHE_MIDDLEWARE_KEY_PREFIX CACHE_MIDDLEWARE_KEY_PREFIX diff --git a/docs/releases/1.6.txt b/docs/releases/1.6.txt index ef79e5770c..f8e1fd6339 100644 --- a/docs/releases/1.6.txt +++ b/docs/releases/1.6.txt @@ -569,6 +569,23 @@ If necessary, you can temporarily disable auto-escaping with :func:`~django.utils.safestring.mark_safe` or :ttag:`{% autoescape off %} `. +``CACHE_MIDDLEWARE_ANONYMOUS_ONLY`` setting +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +``CacheMiddleware`` used to provide a way to cache requests only if they +weren't made by a logged-in user. This mechanism was largely ineffective +because the middleware correctly takes into account the ``Vary: Cookie`` HTTP +header, and this header is being set on a variety of occasions, such as: + +* accessing the session, or +* using CSRF protection, which is turned on by default, or +* using a client-side library which sets cookies, like `Google Analytics`__. + +This makes the cache effectively work on a per-session basis regardless of the +``CACHE_MIDDLEWARE_ANONYMOUS_ONLY`` setting. + +__ http://www.google.com/analytics/ + ``SEND_BROKEN_LINK_EMAILS`` setting ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/docs/topics/cache.txt b/docs/topics/cache.txt index a7d54fbeb0..46911a593f 100644 --- a/docs/topics/cache.txt +++ b/docs/topics/cache.txt @@ -443,15 +443,9 @@ Then, add the following required settings to your Django settings file: The cache middleware caches GET and HEAD responses with status 200, where the request and response headers allow. Responses to requests for the same URL with different query parameters are considered to be unique pages and are cached separately. -Optionally, if the :setting:`CACHE_MIDDLEWARE_ANONYMOUS_ONLY` -setting is ``True``, only anonymous requests (i.e., not those made by a -logged-in user) will be cached. This is a simple and effective way of disabling -caching for any user-specific pages (including Django's admin interface). Note -that if you use :setting:`CACHE_MIDDLEWARE_ANONYMOUS_ONLY`, you should make -sure you've activated ``AuthenticationMiddleware``. The cache middleware -expects that a HEAD request is answered with the same response headers as -the corresponding GET request; in which case it can return a cached GET -response for HEAD request. +The cache middleware expects that a HEAD request is answered with the same +response headers as the corresponding GET request; in which case it can return +a cached GET response for HEAD request. Additionally, the cache middleware automatically sets a few headers in each :class:`~django.http.HttpResponse`: diff --git a/tests/cache/tests.py b/tests/cache/tests.py index 4f7ee8b525..231a3bfb50 100644 --- a/tests/cache/tests.py +++ b/tests/cache/tests.py @@ -28,8 +28,8 @@ from django.middleware.cache import (FetchFromCacheMiddleware, from django.template import Template from django.template.response import TemplateResponse from django.test import TestCase, TransactionTestCase, RequestFactory -from django.test.utils import override_settings, six -from django.utils import timezone, translation, unittest +from django.test.utils import override_settings, IgnorePendingDeprecationWarningsMixin +from django.utils import six, timezone, translation, unittest from django.utils.cache import (patch_vary_headers, get_cache_key, learn_cache_key, patch_cache_control, patch_response_headers) from django.utils.encoding import force_text @@ -1592,9 +1592,10 @@ def hello_world_view(request, value): }, }, ) -class CacheMiddlewareTest(TestCase): +class CacheMiddlewareTest(IgnorePendingDeprecationWarningsMixin, TestCase): def setUp(self): + super(CacheMiddlewareTest, self).setUp() self.factory = RequestFactory() self.default_cache = get_cache('default') self.other_cache = get_cache('other') @@ -1602,6 +1603,7 @@ class CacheMiddlewareTest(TestCase): def tearDown(self): self.default_cache.clear() self.other_cache.clear() + super(CacheMiddlewareTest, self).tearDown() def test_constructor(self): """ -- cgit v1.3 From a9b98f59aaff3f7281fedb27563a263dbb7753ec Mon Sep 17 00:00:00 2001 From: Aymeric Augustin Date: Sun, 19 May 2013 15:23:11 +0200 Subject: Clarified when triagers should close tickets as needsinfo. https://groups.google.com/d/msg/django-developers/dyldP9kFADc/rHTlRBVEP8MJ --- docs/internals/contributing/triaging-tickets.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'docs/internals') diff --git a/docs/internals/contributing/triaging-tickets.txt b/docs/internals/contributing/triaging-tickets.txt index bc6148ca46..43b799ed51 100644 --- a/docs/internals/contributing/triaging-tickets.txt +++ b/docs/internals/contributing/triaging-tickets.txt @@ -349,8 +349,9 @@ Then, you can help out by: * Closing "Unreviewed" tickets as "invalid", "worksforme" or "duplicate." -* Closing "Unreviewed" tickets as "needsinfo" when they're feature requests - requiring a discussion on `django-developers`_. +* Closing "Unreviewed" tickets as "needsinfo" when the description is too + sparse to be actionnable, or when they're feature requests requiring a + discussion on `django-developers`_. * Correcting the "Needs tests", "Needs documentation", or "Has patch" flags for tickets where they are incorrectly set. -- cgit v1.3 From 490672f057cf1660606eeb14ef7f833ecff3df32 Mon Sep 17 00:00:00 2001 From: Tim Graham Date: Mon, 20 May 2013 13:45:32 -0400 Subject: Tweaked unit test 'quick start' explanation. Thanks Jeremy Dunck. --- .../contributing/writing-code/unit-tests.txt | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) (limited to 'docs/internals') diff --git a/docs/internals/contributing/writing-code/unit-tests.txt b/docs/internals/contributing/writing-code/unit-tests.txt index f56bf1cdeb..0737b84888 100644 --- a/docs/internals/contributing/writing-code/unit-tests.txt +++ b/docs/internals/contributing/writing-code/unit-tests.txt @@ -27,15 +27,13 @@ Quickstart Running the tests requires a Django settings module that defines the databases to use. To make it easy to get started, Django provides a sample settings module that uses the SQLite database. To run the tests -with this sample ``settings`` module, ``cd`` into the Django -``tests/`` directory and run: +with this sample ``settings`` module: .. code-block:: bash - ./runtests.py --settings=test_sqlite - -If you get an ``ImportError: No module named django.contrib`` error, -you need to add your install of Django to your ``PYTHONPATH``. + git clone git@github.com:django/django.git django-repo + cd django-repo/tests + PYTHONPATH=..:$PYTHONPATH python ./runtests.py --settings=test_sqlite .. _running-unit-tests-settings: @@ -47,14 +45,10 @@ SQLite. If you want to test behavior using a different database (and if you're proposing patches for Django, it's a good idea to test across databases), you may need to define your own settings file. -To run the tests with different settings, ``cd`` to the ``tests/`` directory -and type: - -.. code-block:: bash - - ./runtests.py --settings=path.to.django.settings +To run the tests with different settings, ensure that the module is on your +``PYTHONPATH`` and pass the module with ``--settings``. -The :setting:`DATABASES` setting in this test settings module needs to define +The :setting:`DATABASES` setting in any test settings module needs to define two databases: * A ``default`` database. This database should use the backend that -- cgit v1.3 From 4ba1c2e785feecfa7a47aa5336a2b595f086a765 Mon Sep 17 00:00:00 2001 From: Ramiro Morales Date: Mon, 15 Apr 2013 10:54:37 -0300 Subject: Fixed #9321 -- Deprecated hard-coding of help text in model ManyToManyField fields. This is backward incompatible for custom form field/widgets that rely on the hard-coded 'Hold down "Control", or "Command" on a Mac, to select more than one.' sentence. Application that use standard model form fields and widgets aren't affected but need to start handling these help texts by themselves before Django 1.8. For more details, see the related release notes and deprecation timeline sections added with this commit. --- django/db/models/fields/related.py | 5 +--- django/forms/models.py | 5 +++- docs/internals/deprecation.txt | 5 ++++ docs/releases/1.6.txt | 51 ++++++++++++++++++++++++++++++++++++++ 4 files changed, 61 insertions(+), 5 deletions(-) (limited to 'docs/internals') diff --git a/django/db/models/fields/related.py b/django/db/models/fields/related.py index 256c3e0f61..fd0b24433f 100644 --- a/django/db/models/fields/related.py +++ b/django/db/models/fields/related.py @@ -11,7 +11,7 @@ from django.db.models.deletion import CASCADE from django.utils.encoding import smart_text from django.utils import six from django.utils.deprecation import RenameMethodsBase -from django.utils.translation import ugettext_lazy as _, string_concat +from django.utils.translation import ugettext_lazy as _ from django.utils.functional import curry, cached_property from django.core import exceptions from django import forms @@ -1348,9 +1348,6 @@ class ManyToManyField(RelatedField): super(ManyToManyField, self).__init__(**kwargs) - msg = _('Hold down "Control", or "Command" on a Mac, to select more than one.') - self.help_text = string_concat(self.help_text, ' ', msg) - def _get_path_info(self, direct=False): """ Called by both direct an indirect m2m traversal. diff --git a/django/forms/models.py b/django/forms/models.py index 93c8b89efe..68c1341cf7 100644 --- a/django/forms/models.py +++ b/django/forms/models.py @@ -18,7 +18,7 @@ from django.utils.encoding import smart_text, force_text from django.utils.datastructures import SortedDict from django.utils import six from django.utils.text import get_text_list, capfirst -from django.utils.translation import ugettext_lazy as _, ugettext +from django.utils.translation import ugettext_lazy as _, ugettext, string_concat __all__ = ( @@ -1104,6 +1104,9 @@ class ModelMultipleChoiceField(ModelChoiceField): super(ModelMultipleChoiceField, self).__init__(queryset, None, cache_choices, required, widget, label, initial, help_text, *args, **kwargs) + if isinstance(self.widget, SelectMultiple): + msg = _('Hold down "Control", or "Command" on a Mac, to select more than one.') + self.help_text = string_concat(self.help_text, ' ', msg) if self.help_text else msg def clean(self, value): if self.required and not value: diff --git a/docs/internals/deprecation.txt b/docs/internals/deprecation.txt index 095b6d0a33..5fa7ea16ac 100644 --- a/docs/internals/deprecation.txt +++ b/docs/internals/deprecation.txt @@ -392,6 +392,11 @@ these changes. * The ``CACHE_MIDDLEWARE_ANONYMOUS_ONLY`` setting will be removed. +* Usage of the hard-coded *Hold down "Control", or "Command" on a Mac, to select + more than one.* string to override or append to user-provided ``help_text`` in + forms for ManyToMany model fields will not be performed by Django anymore + either at the model or forms layer. + 2.0 --- diff --git a/docs/releases/1.6.txt b/docs/releases/1.6.txt index 9950717420..a417e81f62 100644 --- a/docs/releases/1.6.txt +++ b/docs/releases/1.6.txt @@ -481,6 +481,44 @@ parameters. For example:: ``SQLite`` users need to check and update such queries. +.. _m2m-help_text: + +Help text of model form fields for ManyToManyField fields +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +HTML rendering of model form fields corresponding to +:class:`~django.db.models.ManyToManyField` ORM model fields used to get the +hard-coded sentence + + *Hold down "Control", or "Command" on a Mac, to select more than one.* + +(or its translation to the active locale) imposed as the help legend shown along +them if neither :attr:`model ` nor :attr:`form +` ``help_text`` attribute was specified by the +user (or appended to, if ``help_text`` was provided.) + +This happened always, possibly even with form fields implementing user +interactions that don't involve a keyboard and/or a mouse and was handled at the +model field layer. + +Starting with Django 1.6 this doesn't happen anymore. + +The change can affect you in a backward incompatible way if you employ custom +model form fields and/or widgets for ``ManyToManyField`` model fields whose UIs +do rely on the automatic provision of the mentioned hard-coded sentence. These +form field implementations need to adapt to the new scenario by providing their +own handling of the ``help_text`` attribute. + +Applications that use Django :doc:`model form ` +facilities together with Django built-in form :doc:`fields ` +and :doc:`widgets ` aren't affected but need to be aware of +what's described in :ref:`m2m-help_text-deprecation` below. + +This is because, as an temporary backward-compatible provision, the described +non-standard behavior has been preserved but moved to the model form field layer +and occurs only when the associated widget is +:class:`~django.forms.SelectMultiple` or a subclass. + Miscellaneous ~~~~~~~~~~~~~ @@ -707,3 +745,16 @@ you can set set the ``form_class`` attribute to a ``ModelForm`` that explicitly defines the fields to be used. Defining an ``UpdateView`` or ``CreateView`` subclass to be used with a model but without an explicit list of fields is deprecated. + +.. _m2m-help_text-deprecation: + +Munging of help text of model form fields for ManyToManyField fields +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +All special handling of the ``help_text`` attibute of ManyToManyField model +fields performed by standard model or model form fields as described in +:ref:`m2m-help_text` above is deprecated and will be removed in Django 1.8. + +Help text of these fields will need to be handled either by applications, custom +form fields or widgets, just like happens with the rest of the model field +types. -- cgit v1.3 From 01948e384f5508c126c7216e43db3654bf6330f0 Mon Sep 17 00:00:00 2001 From: Tim Graham Date: Wed, 22 May 2013 10:22:32 -0400 Subject: Clarified policy for stable branches. Thanks Ramiro Morales for the initial patch and Preston Holmes for the review. --- docs/internals/git.txt | 76 ++++++++++++++++++++++---------------- docs/internals/release-process.txt | 76 ++++++++++++++++++-------------------- 2 files changed, 81 insertions(+), 71 deletions(-) (limited to 'docs/internals') diff --git a/docs/internals/git.txt b/docs/internals/git.txt index 2b1a279d89..3904ff83d4 100644 --- a/docs/internals/git.txt +++ b/docs/internals/git.txt @@ -35,8 +35,9 @@ The Git repository includes several `branches`_: the next packaged release of Django. This is where most development activity is focused. -* ``stable/A.B.x`` are the maintenance branches. They are used to support - older versions of Django. +* ``stable/A.B.x`` are the branches where release preparation work happens. + They are also used for support and bugfix releases which occur as necessary + after the initial release of a major or minor version. * ``soc20XX/`` branches were used by students who worked on Django during the 2009 and 2010 Google Summer of Code programs. @@ -83,13 +84,50 @@ coding style and how to generate and submit a patch. Other branches ============== -Django uses branches for two main purposes: +Django uses branches to prepare for releases of Django (whether they be +:term:`major `, :term:`minor `, or +:term:`micro `). -1. Development of major or experimental features, to keep them from - affecting progress on other work in master. +In the past when Django was hosted on Subversion, branches were also used for +feature development. Now Django is hosted on Git and feature development is +done on contributor's forks, but the Subversion feature branches remain in Git +for historical reference. -2. Security and bugfix support for older releases of Django, during - their support lifetimes. +Stable branches +--------------- + +These branches can be found in the repository as ``stable/A.B.x`` +branches and will be created right after the first alpha is tagged. + +For example, immediately after *Django 1.5 alpha 1* was tagged, the branch +``stable/1.5.x`` was created and all further work on preparing the code for the +final 1.5 release was done there. + +These branches also provide limited bugfix support for the most recent released +version of Django and security support for the two most recently-released +versions of Django. + +For example, after the release of Django 1.5, the branch ``stable/1.5.x`` +receives only fixes for security and critical stability bugs, which are +eventually released as Django 1.5.1 and so on, ``stable/1.4.x`` receives only +security fixes, and ``stable/1.3.x`` no longer receives any updates. + +.. admonition:: Historical information + + This policy for handling ``stable/A.B.x`` branches was adopted starting + with the Django 1.5 release cycle. + + Previously, these branches weren't created until right after the releases + and the stabilization work occurred on the main repository branch. Thus, + no new features development work for the next release of Django could be + committed until the final release happened. + + For example, shortly after the release of Django 1.3 the branch + ``stable/1.3.x`` was created. Official support for that release has expired, + and so it no longer receives direct maintenance from the Django project. + However, that and all other similarly named branches continue to exist and + interested community members have occasionally used them to provide + unofficial support for old Django releases. Feature-development branches ---------------------------- @@ -203,30 +241,6 @@ All of the above-mentioned branches now reside in ``attic``. Finally, the repository contains ``soc2009/xxx`` and ``soc2010/xxx`` feature branches, used for Google Summer of Code projects. -Support and bugfix branches ---------------------------- - -In addition to fixing bugs in current master, the Django project provides -official bugfix support for the most recent released version of Django, and -security support for the two most recently-released versions of Django. - -This support is provided via branches in which the necessary bug or security -fixes are applied; the branches are then used as the basis for issuing bugfix -or security releases. - -These branches can be found in the repository as ``stable/A.B.x`` -branches, and new branches will be created there after each new Django -release. - -For example, shortly after the release of Django 1.0, the branch -``stable/1.0.x`` was created to receive bug fixes, and shortly after the -release of Django 1.1 the branch ``stable/1.1.x`` was created. - -Official support for the above mentioned releases has expired, and so they no -longer receive direct maintenance from the Django project. However, the -branches continue to exist and interested community members have occasionally -used them to provide unofficial support for old Django releases. - Tags ==== diff --git a/docs/internals/release-process.txt b/docs/internals/release-process.txt index 29ce3914b4..2003e79079 100644 --- a/docs/internals/release-process.txt +++ b/docs/internals/release-process.txt @@ -39,49 +39,45 @@ issued from those branches. For more information about how the Django project issues new releases for security purposes, please see :doc:`our security policies `. -Major releases --------------- +.. glossary:: -Major releases (1.0, 2.0, etc.) will happen very infrequently (think "years", -not "months"), and may represent major, sweeping changes to Django. + Major release + Major releases (1.0, 2.0, etc.) will happen very infrequently (think "years", + not "months"), and may represent major, sweeping changes to Django. -Minor releases --------------- + Minor release + Minor release (1.5, 1.6, etc.) will happen roughly every nine months -- see + `release process`_, below for details. These releases will contain new + features, improvements to existing features, and such. -Minor release (1.5, 1.6, etc.) will happen roughly every nine months -- see -`release process`_, below for details. These releases will contain new -features, improvements to existing features, and such. + .. _internal-release-deprecation-policy: -.. _internal-release-deprecation-policy: + A minor release may deprecate certain features from previous releases. If a + feature is deprecated in version ``A.B``, it will continue to work in versions + ``A.B`` and ``A.B+1`` but raise warnings. It will be removed in version + ``A.B+2``. -A minor release may deprecate certain features from previous releases. If a -feature is deprecated in version ``A.B``, it will continue to work in versions -``A.B`` and ``A.B+1`` but raise warnings. It will be removed in version -``A.B+2``. + So, for example, if we decided to start the deprecation of a function in + Django 1.5: -So, for example, if we decided to start the deprecation of a function in -Django 1.5: + * Django 1.5 will contain a backwards-compatible replica of the function which + will raise a ``PendingDeprecationWarning``. This warning is silent by + default; you can turn on display of these warnings with the ``-Wd`` option + of Python. -* Django 1.5 will contain a backwards-compatible replica of the function which - will raise a ``PendingDeprecationWarning``. This warning is silent by - default; you can turn on display of these warnings with the ``-Wd`` option - of Python. + * Django 1.6 will contain the backwards-compatible replica, but the warning + will be promoted to a full-fledged ``DeprecationWarning``. This warning is + *loud* by default, and will likely be quite annoying. -* Django 1.6 will contain the backwards-compatible replica, but the warning - will be promoted to a full-fledged ``DeprecationWarning``. This warning is - *loud* by default, and will likely be quite annoying. + * Django 1.7 will remove the feature outright. -* Django 1.7 will remove the feature outright. + Micro release + Micro releases (1.5.1, 1.6.2, 1.6.1, etc.) will be issued as needed, often to + fix security issues. -Micro releases --------------- - -Micro releases (1.5.1, 1.6.2, 1.6.1, etc.) will be issued as needed, often to -fix security issues. - -These releases will be 100% compatible with the associated minor release, unless -this is impossible for security reasons. So the answer to "should I upgrade to -the latest micro release?" will always be "yes." + These releases will be 100% compatible with the associated minor release, unless + this is impossible for security reasons. So the answer to "should I upgrade to + the latest micro release?" will always be "yes." .. _backwards-compatibility-policy: @@ -126,15 +122,15 @@ Django 1.6 and 1.7. At this point in time: * Features will be added to development master, to be released as Django 1.7. -* Critical bug fixes will be applied to the ``stable/1.6.X`` branch, and +* Critical bug fixes will be applied to the ``stable/1.6.x`` branch, and released as 1.6.1, 1.6.2, etc. -* Security fixes will be applied to ``master``, to the ``stable/1.6.X`` - branch, and to the ``stable/1.5.X`` branch. They will trigger the release of +* Security fixes will be applied to ``master``, to the ``stable/1.6.x`` + branch, and to the ``stable/1.5.x`` branch. They will trigger the release of ``1.6.1``, ``1.5.1``, etc. * Documentation fixes will be applied to master, and, if easily backported, to - the ``1.6.X`` branch. Bugfixes may also be backported. + the ``1.6.x`` branch. Bugfixes may also be backported. .. _release-process: @@ -193,9 +189,9 @@ Phase two will culminate with an alpha release. At this point, the Phase three: bugfixes ~~~~~~~~~~~~~~~~~~~~~ -The last third of a release is spent fixing bugs -- no new features will be -accepted during this time. We'll try to release a beta release after one month -and a release candidate after two months. +The last third of a release cycle is spent fixing bugs -- no new features will +be accepted during this time. We'll try to release a beta release after one +month and a release candidate after two months. The release candidate marks the string freeze, and it happens at least two weeks before the final release. After this point, new translatable strings -- cgit v1.3 From 499a745ae1b53614035b9993b148f32d4ce3f138 Mon Sep 17 00:00:00 2001 From: Claude Paroz Date: Tue, 21 May 2013 11:11:05 +0200 Subject: Fixed #20474 -- Proxied and deprecated django.db.backend --- django/db/__init__.py | 24 +++++++++++++++++++++++- docs/internals/deprecation.txt | 1 + tests/backends/tests.py | 9 ++++++--- 3 files changed, 30 insertions(+), 4 deletions(-) (limited to 'docs/internals') diff --git a/django/db/__init__.py b/django/db/__init__.py index 08c901ab7b..077e1b2d8b 100644 --- a/django/db/__init__.py +++ b/django/db/__init__.py @@ -8,6 +8,7 @@ from django.db.utils import (DEFAULT_DB_ALIAS, ProgrammingError, NotSupportedError, DatabaseError, InterfaceError, Error, load_backend, ConnectionHandler, ConnectionRouter) +from django.utils.functional import cached_property __all__ = ('backend', 'connection', 'connections', 'router', 'DatabaseError', 'IntegrityError', 'DEFAULT_DB_ALIAS') @@ -45,7 +46,28 @@ class DefaultConnectionProxy(object): return delattr(connections[DEFAULT_DB_ALIAS], name) connection = DefaultConnectionProxy() -backend = load_backend(connection.settings_dict['ENGINE']) + +class DefaultBackendProxy(object): + """ + Temporary proxy class used during deprecation period of the `backend` module + variable. + """ + @cached_property + def _backend(self): + warnings.warn("Accessing django.db.backend is deprecated.", + PendingDeprecationWarning, stacklevel=2) + return load_backend(connections[DEFAULT_DB_ALIAS].settings_dict['ENGINE']) + + def __getattr__(self, item): + return getattr(self._backend, item) + + def __setattr__(self, name, value): + return setattr(self._backend, name, value) + + def __delattr__(self, name): + return delattr(self._backend, name) + +backend = DefaultBackendProxy() def close_connection(**kwargs): warnings.warn( diff --git a/docs/internals/deprecation.txt b/docs/internals/deprecation.txt index 5fa7ea16ac..c4bbc3b7a4 100644 --- a/docs/internals/deprecation.txt +++ b/docs/internals/deprecation.txt @@ -373,6 +373,7 @@ these changes. * The following private APIs will be removed: + - ``django.db.backend`` - ``django.db.close_connection()`` - ``django.db.backends.creation.BaseDatabaseCreation.set_autocommit()`` - ``django.db.transaction.is_managed()`` diff --git a/tests/backends/tests.py b/tests/backends/tests.py index 79e3dd444e..08cae0f7c3 100644 --- a/tests/backends/tests.py +++ b/tests/backends/tests.py @@ -8,7 +8,7 @@ import threading from django.conf import settings from django.core.management.color import no_style -from django.db import (backend, connection, connections, DEFAULT_DB_ALIAS, +from django.db import (connection, connections, DEFAULT_DB_ALIAS, DatabaseError, IntegrityError, transaction) from django.db.backends.signals import connection_created from django.db.backends.postgresql_psycopg2 import version as pg_version @@ -50,7 +50,8 @@ class OracleChecks(unittest.TestCase): def test_dbms_session(self): # If the backend is Oracle, test that we can call a standard # stored procedure through our cursor wrapper. - convert_unicode = backend.convert_unicode + from django.db.backends.oracle.base import convert_unicode + cursor = connection.cursor() cursor.callproc(convert_unicode('DBMS_SESSION.SET_IDENTIFIER'), [convert_unicode('_django_testing!')]) @@ -60,8 +61,10 @@ class OracleChecks(unittest.TestCase): def test_cursor_var(self): # If the backend is Oracle, test that we can pass cursor variables # as query parameters. + from django.db.backends.oracle.base import Database + cursor = connection.cursor() - var = cursor.var(backend.Database.STRING) + var = cursor.var(Database.STRING) cursor.execute("BEGIN %s := 'X'; END; ", [var]) self.assertEqual(var.getvalue(), 'X') -- cgit v1.3 From ec5dc0010c30f9ca7e9294b97e909f5b47ac1683 Mon Sep 17 00:00:00 2001 From: Andrew Godwin Date: Thu, 23 May 2013 15:14:31 +0100 Subject: Fixing some FIXMEs in howto-release-django. Refs #20082 --- docs/internals/howto-release-django.txt | 49 +++++++++++++++++++++++++++------ 1 file changed, 41 insertions(+), 8 deletions(-) (limited to 'docs/internals') diff --git a/docs/internals/howto-release-django.txt b/docs/internals/howto-release-django.txt index fd985ddafc..5bda2e8add 100644 --- a/docs/internals/howto-release-django.txt +++ b/docs/internals/howto-release-django.txt @@ -183,13 +183,46 @@ OK, this is the fun part, where we actually push out a release! $ md5sum dist/Django-* $ sha1sum dist/Django-* - *FIXME: perhaps we should switch to sha256?* - #. Create a "checksums" file containing the hashes and release information. - You can start with `a previous checksums file`__ and replace the - dates, keys, links, and checksums. *FIXME: make a template file.* + Start with this template and insert the correct version, date, release URL + and checksums:: + + This file contains MD5 and SHA1 checksums for the source-code tarball + of Django <>, released <>. + + To use this file, you will need a working install of PGP or other + compatible public-key encryption software. You will also need to have + the Django release manager's public key in your keyring; this key has + the ID ``0x3684C0C08C8B2AE1`` and can be imported from the MIT + keyserver. For example, if using the open-source GNU Privacy Guard + implementation of PGP:: + + gpg --keyserver pgp.mit.edu --recv-key 0x3684C0C08C8B2AE1 + + Once the key is imported, verify this file:: + + gpg --verify <> + + Once you have verified this file, you can use normal MD5 and SHA1 + checksumming applications to generate the checksums of the Django + package and compare them to the checksums listed below. + + + Release package: + ================ + + Django <>: https://www.djangoproject.com/m/releases/<> + + + MD5 checksum: + ============= + + MD5(<>)= <> + + SHA1 checksum: + ============== - __ https://www.djangoproject.com/m/pgp/Django-1.5b1.checksum.txt + SHA1(<>)= <> #. Sign the checksum file (``gpg --clearsign Django-.checksum.txt``). This generates a signed document, @@ -268,8 +301,7 @@ Now you're ready to actually put the release out there. To do this: of the docs by flipping the ``is_default`` flag to ``True`` on the appropriate ``DocumentRelease`` object in the ``docs.djangoproject.com`` database (this will automatically flip it to ``False`` for all - others). *FIXME: I had to do this via fab managepy:shell,docs but we should - probably make it possible to do via the admin.* + others); you can do this using the site's admin. #. Post the release announcement to the django-announce, django-developers and django-users mailing lists. This should @@ -289,7 +321,8 @@ You're almost done! All that's left to do now is: ``stable/1.?.x`` git branch), you'll want to create a new ``DocumentRelease`` object in the ``docs.djangoproject.com`` database for the new version's docs, and update the ``docs/fixtures/doc_releases.json`` - JSON fixture. *FIXME: what is the purpose of maintaining this fixture?* + JSON fixture, so people without access to the production DB can still + run an up-to-date copy of the docs site. #. Add the release in `Trac's versions list`_ if necessary. Not all versions are declared; take example on previous releases. -- cgit v1.3 From cf007f0cbfe936ff699d761b243343201ca5c195 Mon Sep 17 00:00:00 2001 From: Alex Gaynor Date: Thu, 23 May 2013 07:22:52 -0700 Subject: Update my employer. --- docs/internals/committers.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs/internals') diff --git a/docs/internals/committers.txt b/docs/internals/committers.txt index 131f9c0f26..ffe7f578f9 100644 --- a/docs/internals/committers.txt +++ b/docs/internals/committers.txt @@ -243,7 +243,7 @@ Karen Tracey .. _James Tauber: http://jtauber.com/ `Alex Gaynor`_ - Alex is a software engineer working at Rdio_. He found Django in 2007 and + Alex is a software engineer working at Rackspace_. He found Django in 2007 and has been addicted ever since he found out you don't need to write out your forms by hand. He has a small obsession with compilers. He's contributed to the ORM, forms, admin, and other components of Django. @@ -251,7 +251,7 @@ Karen Tracey Alex lives in San Francisco, CA, USA. .. _Alex Gaynor: http://alexgaynor.net -.. _Rdio: http://rdio.com +.. _Rackspace: http://www.rackspace.com `Simon Meers`_ Simon discovered Django 0.96 during his Computer Science PhD research and -- cgit v1.3 From 5a62236b169e74f627492a90b091e8c9339a0181 Mon Sep 17 00:00:00 2001 From: Tim Graham Date: Thu, 23 May 2013 10:48:36 -0400 Subject: Added back a link to docs/internals/committers.txt --- docs/internals/committers.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'docs/internals') diff --git a/docs/internals/committers.txt b/docs/internals/committers.txt index ffe7f578f9..9400f1747c 100644 --- a/docs/internals/committers.txt +++ b/docs/internals/committers.txt @@ -53,6 +53,7 @@ Journal-World`_ of Lawrence, Kansas, USA. .. _revolution systems: http://revsys.com/ .. _wilson miner: http://wilsonminer.com/ .. _heroku: http://heroku.com/ +.. _Rdio: http://rdio.com Current developers ================== -- cgit v1.3 From f3ba6495e29d84f8d98a2acd390821ff0d23fd7a Mon Sep 17 00:00:00 2001 From: Brian Rosner Date: Fri, 24 May 2013 08:22:08 -0600 Subject: Updated my bio --- docs/internals/committers.txt | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) (limited to 'docs/internals') diff --git a/docs/internals/committers.txt b/docs/internals/committers.txt index 9400f1747c..b56c8e469b 100644 --- a/docs/internals/committers.txt +++ b/docs/internals/committers.txt @@ -174,10 +174,10 @@ Joseph Kocherhans .. _charango: http://en.wikipedia.org/wiki/Charango `Brian Rosner`_ - Brian is currently the tech lead at Eldarion_ managing and developing + Brian is the Chief Architect at Eldarion_ managing and developing Django / Pinax_ based Web sites. He enjoys learning more about programming languages and system architectures and contributing to open source - projects. Brian is the host of the `Django Dose`_ podcasts. + projects. Brian helped immensely in getting Django's "newforms-admin" branch finished in time for Django 1.0; he's now a full committer, continuing to improve on @@ -187,7 +187,6 @@ Joseph Kocherhans .. _brian rosner: http://brosner.com/ .. _eldarion: http://eldarion.com/ -.. _django dose: http://djangodose.com/ .. _pinax: http://pinaxproject.com/ Justin Bronn -- cgit v1.3 From cd79f337233be3f2dfa22316314c9d4834093e31 Mon Sep 17 00:00:00 2001 From: Carl Meyer Date: Mon, 27 May 2013 14:41:39 -0600 Subject: Fixed #20503 - Moved doctest utilities in with the rest of the deprecated test code. The ``DocTestRunner`` and ``OutputChecker`` were formerly in ``django.test.testcases``, now they are in ``django.test.simple``. This avoids triggering the ``django.test._doctest`` deprecation message with any import from ``django.test``. Since these utility classes are undocumented internal API, they can be moved without a separate deprecation process. Also removed the deprecation warnings specific to these classes, as they are now covered by the module-level warning in ``django.test.simple``. Thanks Anssi for the report. Refs #17365. --- django/test/simple.py | 70 +++++++++++++++++++++++++++++++++++-- django/test/testcases.py | 79 ++---------------------------------------- docs/internals/deprecation.txt | 6 ++-- docs/releases/1.6.txt | 18 ++++------ 4 files changed, 78 insertions(+), 95 deletions(-) (limited to 'docs/internals') diff --git a/django/test/simple.py b/django/test/simple.py index 5117c6452f..f28b8a2830 100644 --- a/django/test/simple.py +++ b/django/test/simple.py @@ -3,14 +3,15 @@ This module is pending deprecation as of Django 1.6 and will be removed in version 1.8. """ - +import json +import re import unittest as real_unittest import warnings from django.db.models import get_app, get_apps from django.test import _doctest as doctest from django.test import runner -from django.test.testcases import OutputChecker, DocTestRunner +from django.test.utils import compare_xml, strip_quotes from django.utils import unittest from django.utils.importlib import import_module from django.utils.module_loading import module_has_submodule @@ -25,6 +26,71 @@ warnings.warn( # The module name for tests outside models.py TEST_MODULE = 'tests' + +normalize_long_ints = lambda s: re.sub(r'(?