a
/
applet.miniprograms
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

上传文件至 'test/Django-2.1.15/docs/internals'

This commit is contained in:
a 2022-05-17 21:04:08 +08:00
parent 625dfcbfd6
commit 7fe70e60d0
5 changed files with 1850 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1023
test/Django-2.1.15/docs/internals/deprecation.txt Normal file
View File

File diff suppressed because it is too large Load Diff

249
test/Django-2.1.15/docs/internals/git.txt Normal file
View File

@ -0,0 +1,249 @@
=================================
The Django source code repository
=================================
When deploying a Django application into a real production environment, you
will almost always want to use `an official packaged release of Django`_.
However, if you'd like to try out in-development code from an upcoming release
or contribute to the development of Django, you'll need to obtain a clone of
Django's source code repository.
This document covers the way the code repository is laid out and how to work
with and find things in it.
.. _an official packaged release of Django: https://www.djangoproject.com/download/
High-level overview
===================
The Django source code repository uses `Git`_ to track changes to the code
over time, so you'll need a copy of the Git client (a program called ``git``)
on your computer, and you'll want to familiarize yourself with the basics of
how Git works.
Git's website offers downloads for various operating systems. The site also
contains vast amounts of `documentation`_.
The Django Git repository is located online at `github.com/django/django
<https://github.com/django/django>`_. It contains the full source code for all
Django releases, which you can browse online.
The Git repository includes several `branches`_:
* ``master`` contains the main in-development code which will become
the next packaged release of Django. This is where most development
activity is focused.
* ``stable/A.B.x`` are the branches where release preparation work happens.
They are also used for bugfix and security releases which occur as necessary
after the initial release of a feature version.
* ``soc20XX/<project>`` branches were used by students who worked on Django
during the 2009 and 2010 Google Summer of Code programs.
* ``attic/<project>`` branches were used to develop major or experimental new
features without affecting the rest of Django's code.
The Git repository also contains `tags`_. These are the exact revisions from
which packaged Django releases were produced, since version 1.0.
The source code for the `Djangoproject.com <https://www.djangoproject.com/>`_
website can be found at `github.com/django/djangoproject.com
<https://github.com/django/djangoproject.com>`_.
.. _Git: https://git-scm.com/
.. _documentation: https://git-scm.com/documentation
.. _branches: https://github.com/django/django/branches
.. _tags: https://github.com/django/django/tags
The master branch
=================
If you'd like to try out the in-development code for the next release of
Django, or if you'd like to contribute to Django by fixing bugs or developing
new features, you'll want to get the code from the master branch.
Note that this will get *all* of Django: in addition to the top-level
``django`` module containing Python code, you'll also get a copy of Django's
documentation, test suite, packaging scripts and other miscellaneous bits.
Django's code will be present in your clone as a directory named
``django``.
To try out the in-development code with your own applications, simply place
the directory containing your clone on your Python import path. Then
``import`` statements which look for Django will find the ``django`` module
within your clone.
If you're going to be working on Django's code (say, to fix a bug or
develop a new feature), you can probably stop reading here and move
over to :doc:`the documentation for contributing to Django
</internals/contributing/index>`, which covers things like the preferred
coding style and how to generate and submit a patch.
Other branches
==============
Django uses branches to prepare for releases of Django.
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.
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 bugfix and security support as described in
:ref:`supported-versions-policy`.
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 and data loss 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 feature 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
----------------------------
.. admonition:: Historical information
Since Django moved to Git in 2012, anyone can clone the repository and
create their own branches, alleviating the need for official branches in
the source code repository.
The following section is mostly useful if you're exploring the repository's
history, for example if you're trying to understand how some features were
designed.
Feature-development branches tend by their nature to be temporary. Some
produce successful features which are merged back into Django's master to
become part of an official release, but others do not; in either case, there
comes a time when the branch is no longer being actively worked on by any
developer. At this point the branch is considered closed.
Unfortunately, Django used to be maintained with the Subversion revision
control system, that has no standard way of indicating this. As a workaround,
branches of Django which are closed and no longer maintained were moved into
``attic``.
For reference, the following are branches whose code eventually became
part of Django itself, and so are no longer separately maintained:
* ``boulder-oracle-sprint``: Added support for Oracle databases to
Django's object-relational mapper. This has been part of Django
since the 1.0 release.
* ``gis``: Added support for geographic/spatial queries to Django's
object-relational mapper. This has been part of Django since the 1.0
release, as the bundled application ``django.contrib.gis``.
* ``i18n``: Added :doc:`internationalization support </topics/i18n/index>` to
Django. This has been part of Django since the 0.90 release.
* ``magic-removal``: A major refactoring of both the internals and
public APIs of Django's object-relational mapper. This has been part
of Django since the 0.95 release.
* ``multi-auth``: A refactoring of :doc:`Django's bundled
authentication framework </topics/auth/index>` which added support for
:ref:`authentication backends <authentication-backends>`. This has
been part of Django since the 0.95 release.
* ``new-admin``: A refactoring of :doc:`Django's bundled
administrative application </ref/contrib/admin/index>`. This became part of
Django as of the 0.91 release, but was superseded by another
refactoring (see next listing) prior to the Django 1.0 release.
* ``newforms-admin``: The second refactoring of Django's bundled
administrative application. This became part of Django as of the 1.0
release, and is the basis of the current incarnation of
``django.contrib.admin``.
* ``queryset-refactor``: A refactoring of the internals of Django's
object-relational mapper. This became part of Django as of the 1.0
release.
* ``unicode``: A refactoring of Django's internals to consistently use
Unicode-based strings in most places within Django and Django
applications. This became part of Django as of the 1.0 release.
When Django moved from Subversion to Git, the information about branch merges
wasn't preserved in the source code repository. This means that the ``master``
branch of Django doesn't contain merge commits for the above branches.
However, this information is `available as a grafts file`_. You can restore it
by putting the following lines in ``.git/info/grafts`` in your local clone::
ac64e91a0cadc57f4bc5cd5d66955832320ca7a1 553a20075e6991e7a60baee51ea68c8adc520d9a 0cb8e31823b2e9f05c4ae868c19f5f38e78a5f2e
79e68c225b926302ebb29c808dda8afa49856f5c d0f57e7c7385a112cb9e19d314352fc5ed5b0747 aa239e3e5405933af6a29dac3cf587b59a099927
5cf8f684237ab5addaf3549b2347c3adf107c0a7 cb45fd0ae20597306cd1f877efc99d9bd7cbee98 e27211a0deae2f1d402537f0ebb64ad4ccf6a4da
f69cf70ed813a8cd7e1f963a14ae39103e8d5265 d5dbeaa9be359a4c794885c2e9f1b5a7e5e51fb8 d2fcbcf9d76d5bb8a661ee73dae976c74183098b
aab3a418ac9293bb4abd7670f65d930cb0426d58 4ea7a11659b8a0ab07b0d2e847975f7324664f10 adf4b9311d5d64a2bdd58da50271c121ea22e397
ff60c5f9de3e8690d1e86f3e9e3f7248a15397c8 7ef212af149540aa2da577a960d0d87029fd1514 45b4288bb66a3cda401b45901e85b645674c3988
9dda4abee1225db7a7b195b84c915fdd141a7260 4fe5c9b7ee09dc25921918a6dbb7605edb374bc9 3a7c14b583621272d4ef53061287b619ce3c290d
a19ed8aea395e8e07164ff7d85bd7dff2f24edca dc375fb0f3b7fbae740e8cfcd791b8bccb8a4e66 42ea7a5ce8aece67d16c6610a49560c1493d4653
9c52d56f6f8a9cdafb231adf9f4110473099c9b5 c91a30f00fd182faf8ca5c03cd7dbcf8b735b458 4a5c5c78f2ecd4ed8859cd5ac773ff3a01bccf96
953badbea5a04159adbfa970f5805c0232b6a401 4c958b15b250866b70ded7d82aa532f1e57f96ae 5664a678b29ab04cad425c15b2792f4519f43928
471596fc1afcb9c6258d317c619eaf5fd394e797 4e89105d64bb9e04c409139a41e9c7aac263df4c 3e9035a9625c8a8a5e88361133e87ce455c4fc13
9233d0426537615e06b78d28010d17d5a66adf44 6632739e94c6c38b4c5a86cf5c80c48ae50ac49f 18e151bc3f8a85f2766d64262902a9fcad44d937
.. _available as a grafts file: https://github.com/ramiro/django-git-grafts
Additionally, the following branches are closed, but their code was
never merged into Django and the features they aimed to implement
were never finished:
* ``full-history``
* ``generic-auth``
* ``multiple-db-support``
* ``per-object-permissions``
* ``schema-evolution``
* ``schema-evolution-ng``
* ``search-api``
* ``sqlalchemy``
All of the above-mentioned branches now reside in ``attic``.
Finally, the repository contains ``soc2009/xxx`` and ``soc2010/xxx`` feature
branches, used for the 2009 and 2010 Google Summer of Code projects.
Tags
====
Each Django release is tagged and signed by the releaser.
The tags can be found on GitHub's `tags`_ page.
.. _tags: https://github.com/django/django/tags

434
test/Django-2.1.15/docs/internals/howto-release-django.txt Normal file
View File

@ -0,0 +1,434 @@
=====================
How is Django Formed?
=====================
.. highlight:: console
This document explains how to release Django.
**Please, keep these instructions up-to-date if you make changes!** The point
here is to be descriptive, not prescriptive, so feel free to streamline or
otherwise make changes, but **update this document accordingly!**
Overview
========
There are three types of releases that you might need to make:
* Security releases: disclosing and fixing a vulnerability. This'll
generally involve two or three simultaneous releases -- e.g.
1.5.x, 1.6.x, and, depending on timing, perhaps a 1.7 alpha/beta/rc.
* Regular version releases: either a final release (e.g. 1.5) or a
bugfix update (e.g. 1.5.1).
* Pre-releases: e.g. 1.6 alpha, beta, or rc.
The short version of the steps involved is:
#. If this is a security release, pre-notify the security distribution list
one week before the actual release.
#. Proofread the release notes, looking for organization and writing errors.
Draft a blog post and email announcement.
#. Update version numbers and create the release package(s).
#. Upload the package(s) to the ``djangoproject.com`` server.
#. Upload the new version(s) to PyPI.
#. Declare the new version in the admin on ``djangoproject.com``.
#. Post the blog entry and send out the email announcements.
#. Update version numbers post-release.
There are a lot of details, so please read on.
Prerequisites
=============
You'll need a few things before getting started:
* A GPG key. If the key you want to use is not your default signing key, you'll
need to add ``-u you@example.com`` to every GPG signing command below, where
``you@example.com`` is the email address associated with the key you want to
use.
* An install of some required Python packages::
$ pip install wheel twine
* Access to Django's record on PyPI. Create a file with your credentials:
.. code-block:: ini
:caption: ~/.pypirc
[pypi]
username:YourUsername
password:YourPassword
* Access to the ``djangoproject.com`` server to upload files.
* Access to the admin on ``djangoproject.com`` as a "Site maintainer".
* Access to post to ``django-announce``.
* If this is a security release, access to the pre-notification distribution
list.
If this is your first release, you'll need to coordinate with another releaser
to get all these things lined up.
Pre-release tasks
=================
A few items need to be taken care of before even beginning the release process.
This stuff starts about a week before the release; most of it can be done
any time leading up to the actual release:
#. If this is a security release, send out pre-notification **one week** before
the release. We maintain a list of who gets these pre-notification emails in
the private ``django-core`` repository. Send the mail to
``security@djangoproject.com`` and BCC the pre-notification recipients.
This email should be signed by the key you'll use for the release and
should include `CVE IDs <https://cveform.mitre.org/>`_ (requested with
Vendor: djangoproject, Product: django) and patches for each issue being
fixed. Also, :ref:`notify django-announce <security-disclosure>` of the
upcoming security release.
#. As the release approaches, watch Trac to make sure no release blockers
are left for the upcoming release.
#. Check with the other committers to make sure they don't have any
uncommitted changes for the release.
#. Proofread the release notes, including looking at the online
version to catch any broken links or reST errors, and make sure the
release notes contain the correct date.
#. Double-check that the release notes mention deprecation timelines
for any APIs noted as deprecated, and that they mention any changes
in Python version support.
#. Double-check that the release notes index has a link to the notes
for the new release; this will be in ``docs/releases/index.txt``.
#. If this is a feature release, ensure translations from Transifex have been
integrated. This is typically done by a separate translation's manager
rather than the releaser, but here are the steps. Provided you have an
account on Transifex::
$ python scripts/manage_translations.py fetch
and then commit the changed/added files (both .po and .mo). Sometimes there
are validation errors which need to be debugged, so avoid doing this task
immediately before a release is needed.
#. :ref:`Update the django-admin manual page <django-admin-manpage>`::
$ cd docs
$ make man
$ man _build/man/django-admin.1 # do a quick sanity check
$ cp _build/man/django-admin.1 man/django-admin.1
and then commit the changed man page.
Preparing for release
=====================
Write the announcement blog post for the release. You can enter it into the
admin at any time and mark it as inactive. Here are a few examples: `example
security release announcement`__, `example regular release announcement`__,
`example pre-release announcement`__.
__ https://www.djangoproject.com/weblog/2013/feb/19/security/
__ https://www.djangoproject.com/weblog/2012/mar/23/14/
__ https://www.djangoproject.com/weblog/2012/nov/27/15-beta-1/
Actually rolling the release
============================
OK, this is the fun part, where we actually push out a release!
#. Check `Jenkins`__ is green for the version(s) you're putting out. You
probably shouldn't issue a release until it's green.
__ https://djangoci.com
#. A release always begins from a release branch, so you should make sure
you're on a stable branch and up-to-date. For example::
$ git checkout stable/1.5.x
$ git pull
#. If this is a security release, merge the appropriate patches from
``django-security``. Rebase these patches as necessary to make each one a
simple commit on the release branch rather than a merge commit. To ensure
this, merge them with the ``--ff-only`` flag; for example::
$ git checkout stable/1.5.x
$ git merge --ff-only security/1.5.x
(This assumes ``security/1.5.x`` is a branch in the ``django-security`` repo
containing the necessary security patches for the next release in the 1.5
series.)
If git refuses to merge with ``--ff-only``, switch to the security-patch
branch and rebase it on the branch you are about to merge it into (``git
checkout security/1.5.x; git rebase stable/1.5.x``) and then switch back and
do the merge. Make sure the commit message for each security fix explains
that the commit is a security fix and that an announcement will follow
(:commit:`example security commit <bf39978a53f117ca02e9a0c78b76664a41a54745>`).
#. For a feature release, remove the ``UNDER DEVELOPMENT`` header at the
top of the release notes and add the release date on the next line. For a
patch release, replace ``*Under Development*`` with the release date. Make
this change on all branches where the release notes for a particular version
are located.
#. Update the version number in ``django/__init__.py`` for the release.
Please see `notes on setting the VERSION tuple`_ below for details
on ``VERSION``.
#. If this is a pre-release package, update the "Development Status" trove
classifier in ``setup.py`` to reflect this. Otherwise, make sure the
classifier is set to ``Development Status :: 5 - Production/Stable``.
#. Tag the release using ``git tag``. For example::
$ git tag --sign --message="Tag 1.5.1" 1.5.1
You can check your work by running ``git tag --verify <tag>``.
#. Push your work, including the tag: ``git push --tags``.
#. Make sure you have an absolutely clean tree by running ``git clean -dfx``.
#. Run ``make -f extras/Makefile`` to generate the release packages. This will
create the release packages in a ``dist/`` directory.
#. Generate the hashes of the release packages::
$ cd dist
$ md5sum *
$ sha1sum *
$ sha256sum *
#. Create a "checksums" file, ``Django-<<VERSION>>.checksum.txt`` containing
the hashes and release information. Start with this template and insert the
correct version, date, GPG key ID (from
``gpg --list-keys --keyid-format LONG``), release URL, and checksums:
.. code-block:: text
This file contains MD5, SHA1, and SHA256 checksums for the source-code
tarball and wheel files of Django <<VERSION>>, released <<DATE>>.
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 ``XXXXXXXXXXXXXXXX`` 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 XXXXXXXXXXXXXXXX
Once the key is imported, verify this file::
gpg --verify <<THIS FILENAME>>
Once you have verified this file, you can use normal MD5, SHA1, or SHA256
checksumming applications to generate the checksums of the Django
package and compare them to the checksums listed below.
Release packages:
=================
https://www.djangoproject.com/m/releases/<<RELEASE TAR.GZ FILENAME>>
https://www.djangoproject.com/m/releases/<<RELEASE WHL FILENAME>>
MD5 checksums:
==============
<<MD5SUM>> <<RELEASE TAR.GZ FILENAME>>
<<MD5SUM>> <<RELEASE WHL FILENAME>>
SHA1 checksums:
===============
<<SHA1SUM>> <<RELEASE TAR.GZ FILENAME>>
<<SHA1SUM>> <<RELEASE WHL FILENAME>>
SHA256 checksums:
=================
<<SHA256SUM>> <<RELEASE TAR.GZ FILENAME>>
<<SHA256SUM>> <<RELEASE WHL FILENAME>>
#. Sign the checksum file (``gpg --clearsign --digest-algo SHA256
Django-<version>.checksum.txt``). This generates a signed document,
``Django-<version>.checksum.txt.asc`` which you can then verify using ``gpg
--verify Django-<version>.checksum.txt.asc``.
If you're issuing multiple releases, repeat these steps for each release.
Making the release(s) available to the public
=============================================
Now you're ready to actually put the release out there. To do this:
#. Upload the release package(s) to the djangoproject server, replacing
A.B. with the appropriate version number, e.g. 1.5 for a 1.5.x release::
$ scp Django-* djangoproject.com:/home/www/www/media/releases/A.B
#. Upload the checksum file(s)::
$ scp Django-A.B.C.checksum.txt.asc djangoproject.com:/home/www/www/media/pgp/Django-A.B.C.checksum.txt
#. Test that the release packages install correctly using ``easy_install``
and ``pip``. Here's one method (which requires `virtualenvwrapper`__)::
$ RELEASE_VERSION='1.7.2'
$ MAJOR_VERSION=`echo $RELEASE_VERSION| cut -c 1-3`
$ mktmpenv
$ easy_install https://www.djangoproject.com/m/releases/$MAJOR_VERSION/Django-$RELEASE_VERSION.tar.gz
$ deactivate
$ mktmpenv
$ pip install https://www.djangoproject.com/m/releases/$MAJOR_VERSION/Django-$RELEASE_VERSION.tar.gz
$ deactivate
$ mktmpenv
$ pip install https://www.djangoproject.com/m/releases/$MAJOR_VERSION/Django-$RELEASE_VERSION-py3-none-any.whl
$ deactivate
This just tests that the tarballs are available (i.e. redirects are up) and
that they install correctly, but it'll catch silly mistakes.
__ https://pypi.org/project/virtualenvwrapper/
#. Ask a few people on IRC to verify the checksums by visiting the checksums
file (e.g. https://www.djangoproject.com/m/pgp/Django-1.5b1.checksum.txt)
and following the instructions in it. For bonus points, they can also unpack
the downloaded release tarball and verify that its contents appear to be
correct (proper version numbers, no stray ``.pyc`` or other undesirable
files).
#. Upload the release packages to PyPI (for pre-releases, only upload the wheel
file)::
$ twine upload -s dist/*
#. Go to the `Add release page in the admin`__, enter the new release number
exactly as it appears in the name of the tarball (Django-<version>.tar.gz).
So for example enter "1.5.1" or "1.4c2", etc. If the release is part of
an LTS branch, mark it so.
__ https://www.djangoproject.com/admin/releases/release/add/
#. Make the blog post announcing the release live.
#. For a new version release (e.g. 1.5, 1.6), update the default stable version
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); you can do this using the site's admin.
Create new ``DocumentRelease`` objects for each language that has an entry
for the previous release. Update djangoproject.com's `robots.docs.txt`__
file by copying entries from the previous release.
__ https://github.com/django/djangoproject.com/blob/master/djangoproject/static/robots.docs.txt
#. Post the release announcement to the |django-announce|, |django-developers|,
and |django-users| mailing lists. This should include a link to the
announcement blog post. If this is a security release, also include
oss-security@lists.openwall.com.
#. Add a link to the blog post in the topic of the `#django` IRC channel:
``/msg chanserv TOPIC #django new topic goes here``.
Post-release
============
You're almost done! All that's left to do now is:
#. Update the ``VERSION`` tuple in ``django/__init__.py`` again,
incrementing to whatever the next expected release will be. For
example, after releasing 1.5.1, update ``VERSION`` to
``VERSION = (1, 5, 2, 'alpha', 0)``.
#. Add the release in `Trac's versions list`_ if necessary (and make it the
default if it's a final release). Not all versions are declared;
take example on previous releases.
#. If this was a security release, update :doc:`/releases/security` with
details of the issues addressed.
.. _Trac's versions list: https://code.djangoproject.com/admin/ticket/versions
New stable branch tasks
=======================
There are several items to do in the time following the creation of a new
stable branch (often following an alpha release). Some of these tasks don't
need to be done by the releaser.
#. 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, so people without access
to the production DB can still run an up-to-date copy of the docs site.
#. Create a stub release note for the new feature version. Use the stub from
the previous feature release version or copy the contents from the previous
feature version and delete most of the contents leaving only the headings.
#. Increase the default PBKDF2 iterations in
``django.contrib.auth.hashers.PBKDF2PasswordHasher`` by about 20%
(pick a round number). Run the tests, and update the 3 failing
hasher tests with the new values. Make sure this gets noted in the
release notes (see the 1.8 release notes for an example).
#. Remove features that have reached the end of their deprecation cycle. Each
removal should be done in a separate commit for clarity. In the commit
message, add a "refs #XXXX" to the original ticket where the deprecation
began if possible.
#. Remove ``.. versionadded::``, ``.. versionadded::``, and ``.. deprecated::``
annotations in the documentation from two releases ago. For example, in
Django 1.9, notes for 1.7 will be removed.
#. Add the new branch to `Read the Docs
<https://readthedocs.org/projects/django/>`_. Since the automatically
generated version names ("stable-A.B.x") differ from the version numbers
we've used historically in Read the Docs ("A.B.x"), we currently ask Eric
Holscher to add the version for us. Someday the alias functionality may be
built-in to the Read the Docs UI.
Notes on setting the VERSION tuple
==================================
Django's version reporting is controlled by the ``VERSION`` tuple in
``django/__init__.py``. This is a five-element tuple, whose elements
are:
#. Major version.
#. Minor version.
#. Micro version.
#. Status -- can be one of "alpha", "beta", "rc" or "final".
#. Series number, for alpha/beta/RC packages which run in sequence
(allowing, for example, "beta 1", "beta 2", etc.).
For a final release, the status is always "final" and the series
number is always 0. A series number of 0 with an "alpha" status will
be reported as "pre-alpha".
Some examples:
* ``(1, 2, 1, 'final', 0)`` → "1.2.1"
* ``(1, 3, 0, 'alpha', 0)`` → "1.3 pre-alpha"
* ``(1, 3, 0, 'beta', 2)`` → "1.3 beta 2"

18
test/Django-2.1.15/docs/internals/index.txt Normal file
View File

@ -0,0 +1,18 @@
================
Django internals
================
Documentation for people hacking on Django itself. This is the place to go if
you'd like to help improve Django or learn about how Django is managed.
.. toctree::
:maxdepth: 2
contributing/index
mailing-lists
organization
security
release-process
deprecation
git
howto-release-django

126
test/Django-2.1.15/docs/internals/mailing-lists.txt Normal file
View File

@ -0,0 +1,126 @@
=============
Mailing lists
=============
.. Important::
Please report security issues **only** to
security@djangoproject.com. This is a private list only open to
long-time, highly trusted Django developers, and its archives are
not public. For further details, please see :doc:`our security
policies </internals/security>`.
Django has several official mailing lists on Google Groups that are open to
anyone.
.. _django-users-mailing-list:
``django-users``
================
This is the right place if you are looking to ask any question regarding the
installation, usage, or debugging of Django.
.. note::
If it's the first time you send an email to this list, your email must be
accepted first so don't worry if :ref:`your message does not appear
<message-does-not-appear-on-django-users>` instantly.
* `django-users mailing archive`_
* `django-users subscription email address`_
* `django-users posting email`_
.. _django-users mailing archive: https://groups.google.com/d/forum/django-users
.. _django-users subscription email address: mailto:django-users+subscribe@googlegroups.com
.. _django-users posting email: mailto:django-users@googlegroups.com
.. _django-core-mentorship-mailing-list:
``django-core-mentorship``
==========================
The Django Core Mentorship list is intended to provide a welcoming
introductory environment for community members interested in contributing to
the Django Project.
* `django-core-mentorship mailing archive`_
* `django-core-mentorship subscription email address`_
* `django-core-mentorship posting email`_
.. _django-core-mentorship mailing archive: https://groups.google.com/d/forum/django-core-mentorship
.. _django-core-mentorship subscription email address: mailto:django-core-mentorship+subscribe@googlegroups.com
.. _django-core-mentorship posting email: mailto:django-core-mentorship@googlegroups.com
.. _django-developers-mailing-list:
``django-developers``
=====================
The discussion about the development of Django itself takes place here.
Before asking a question about how to contribute, read
:doc:`/internals/contributing/index`. Many frequently asked questions are
answered there.
.. note::
Please make use of
:ref:`django-users mailing list <django-users-mailing-list>` if you want
to ask for tech support, doing so in this list is inappropriate.
* `django-developers mailing archive`_
* `django-developers subscription email address`_
* `django-developers posting email`_
.. _django-developers mailing archive: https://groups.google.com/d/forum/django-developers
.. _django-developers subscription email address: mailto:django-developers+subscribe@googlegroups.com
.. _django-developers posting email: mailto:django-developers@googlegroups.com
.. _django-i18n-mailing-list:
``django-i18n``
===============
This is the place to discuss the internationalization and localization of
Django's components.
* `django-i18n mailing archive`_
* `django-i18n subscription email address`_
* `django-i18n posting email`_
.. _django-i18n mailing archive: https://groups.google.com/d/forum/django-i18n
.. _django-i18n subscription email address: mailto:django-i18n+subscribe@googlegroups.com
.. _django-i18n posting email: mailto:django-i18n@googlegroups.com
.. _django-announce-mailing-list:
``django-announce``
===================
A (very) low-traffic list for announcing :ref:`upcoming security releases
<security-disclosure>`, new releases of Django, and security advisories.
* `django-announce mailing archive`_
* `django-announce subscription email address`_
* `django-announce posting email`_
.. _django-announce mailing archive: https://groups.google.com/d/forum/django-announce
.. _django-announce subscription email address: mailto:django-announce+subscribe@googlegroups.com
.. _django-announce posting email: mailto:django-announce@googlegroups.com
.. _django-updates-mailing-list:
``django-updates``
==================
All the ticket updates are mailed automatically to this list, which is tracked
by developers and interested community members.
* `django-updates mailing archive`_
* `django-updates subscription email address`_
* `django-updates posting email`_
.. _django-updates mailing archive: https://groups.google.com/d/forum/django-updates
.. _django-updates subscription email address: mailto:django-updates+subscribe@googlegroups.com
.. _django-updates posting email: mailto:django-updates@googlegroups.com