Added docs/internals/mailing-lists.txt documenting the use of django's
mailing lists. All references across docs changed to point to this page.
The referencing makes use of substitution because there's no way to make
a :ref: link in a non-inline fashion in Sphinx. It also makes use of
rst_epilog Sphinx conf for making this substitutions across all the
docs.
The precision of time.time() is OS specific and it is possible for the
resolution to be low enough to allow reading a cache key previously set
with a timeout of 0.
Since non-core contributors are asked to review patches, instructions
on working with pull requests were added to the Working with Git and
GitHub page (based on the existing instructions in the core
committers page).
This commit deprecates django.utils.tzinfo in favor of the more recent
django.utils.timezone which was introduced when Django gained support
for time zones.
* override_settings may now be imported from django.test
* removed Approximate from django.test
* updated documentation for things importable from django.test
Thanks akaariai for the suggestion.
1. Automatically use tests/../django as the Django version.
2. If settings aren't provided through --settings or DJANGO_SETTINGS_MODULE)
then use test_sqlite.
There was some confusion on the mentorship list as to whether 'needs tests'
meant that a given ticket might not need tests, as opposed to flagging
a specific patch as still needing tests.
This commit seeks to clarify that confusion.
uid is now base64 encoded in password reset URLs/views. A backwards compatible
password_reset_confirm view/URL will allow password reset links generated before
this change to continue to work. This view will be removed in Django 1.7.
Thanks jonash for the initial patch and claudep for the review.
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.
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.
Thanks to Preston Timmons for the bulk of the work on the patch, especially
updating Django's own test suite to comply with the requirements of the new
runner. Thanks also to Jannis Leidel and Mahdi Yusuf for earlier work on the
patch and the discovery runner.
Refs #11077, #17032, and #18670.
Translations for the Django framework are now hosted on the
django-core Transifex project, and the django project is only
dedicated to a team-only hub project.
As explained in ticket #20104, the use of versionchanged/versionadded
was confusing.
To solve this ambiguity these directives no longer accept a second
argument but now they only receive the version number (1st arg) and then
a content with the proper comment.
I refactored RadioSelect and CheckboxSelectMultiple to
make them inherit from a base class, allowing them to share
the behavior of being able to iterate over their subwidgets.
Thanks to Matt McClanahan for the initial patch and to
Claude Paroz for the review.
Now that DDN is gone, I felt it was worth some extra language
about what "accepted" means, and qualify what it means to be "safe"
to start writing a patch.
Replaced them with per-database options, for proper multi-db support.
Also toned down the recommendation to tie transactions to HTTP requests.
Thanks Jeremy for sharing his experience.
Since "unless managed" now means "if database-level autocommit",
committing or rolling back doesn't have any effect.
Restored transactional integrity in a few places that relied on
automatically-started transactions with a transitory API.
enter_transaction_management() was nearly always followed by managed().
In three places it wasn't, but they will all be refactored eventually.
The "forced" keyword argument avoids introducing behavior changes until
then.
This is mostly backwards-compatible, except, of course, for managed
itself. There's a minor difference in _enter_transaction_management:
the top self.transaction_state now contains the new 'managed' state
rather than the previous one. Django doesn't access
self.transaction_state in _enter_transaction_management.