[1.1.X] Fixed #12609 -- Updated FAQ on which version users should install. Thanks to shanx for the report.
Backport of r13109 from trunk. git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.1.X@13112 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
1d7c4a96ab
commit
760ed9987a
|
@ -87,11 +87,13 @@ See our `Django-friendly Web hosts`_ page.
|
||||||
|
|
||||||
.. _`Django-friendly Web hosts`: http://code.djangoproject.com/wiki/DjangoFriendlyWebHosts
|
.. _`Django-friendly Web hosts`: http://code.djangoproject.com/wiki/DjangoFriendlyWebHosts
|
||||||
|
|
||||||
Should I use the official version or development version?
|
Should I use the stable version or development version?
|
||||||
---------------------------------------------------------
|
-------------------------------------------------------
|
||||||
|
|
||||||
The Django developers improve Django every day and are pretty good about not
|
Generally, if you're using code in production, you should be using a
|
||||||
checking in broken code. We use the development code (from the Subversion
|
stable release. The Django project publishes a full stable release
|
||||||
repository) directly on our servers, so we consider it stable. With that in
|
every nine months or so, with bugfix updates in between. These stable
|
||||||
mind, we recommend that you use the latest development code, because it
|
releases contain the API that is covered by our backwards
|
||||||
generally contains more features and fewer bugs than the "official" releases.
|
compatibility guarantees; if you write code against stable releases,
|
||||||
|
you shouldn't have any problems upgrading when the next official
|
||||||
|
version is released.
|
||||||
|
|
|
@ -47,7 +47,7 @@ not "months"), and will probably represent major, sweeping changes to Django.
|
||||||
Minor releases
|
Minor releases
|
||||||
--------------
|
--------------
|
||||||
|
|
||||||
Minor release (1.1, 1.2, etc.) will happen roughly every six months -- see
|
Minor release (1.1, 1.2, etc.) will happen roughly every nine months -- see
|
||||||
`release process`_, below for details.
|
`release process`_, below for details.
|
||||||
|
|
||||||
.. _internal-release-deprecation-policy:
|
.. _internal-release-deprecation-policy:
|
||||||
|
@ -119,7 +119,7 @@ Release process
|
||||||
===============
|
===============
|
||||||
|
|
||||||
Django uses a time-based release schedule, with minor (i.e. 1.1, 1.2, etc.)
|
Django uses a time-based release schedule, with minor (i.e. 1.1, 1.2, etc.)
|
||||||
releases every six months, or more, depending on features.
|
releases every nine months, or more, depending on features.
|
||||||
|
|
||||||
After each previous release (and after a suitable cooling-off period of a week
|
After each previous release (and after a suitable cooling-off period of a week
|
||||||
or two), the core development team will examine the landscape and announce a
|
or two), the core development team will examine the landscape and announce a
|
||||||
|
|
Loading…
Reference in New Issue