From 92983a3119d6af66b5b2099a0925092d520ee85a Mon Sep 17 00:00:00 2001 From: Russell Keith-Magee Date: Thu, 6 May 2010 01:20:11 +0000 Subject: [PATCH] Fixed #12609 -- Updated FAQ on which version users should install. Thanks to shanx for the report. git-svn-id: http://code.djangoproject.com/svn/django/trunk@13109 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- docs/faq/install.txt | 16 +++++++++------- docs/internals/release-process.txt | 4 ++-- 2 files changed, 11 insertions(+), 9 deletions(-) diff --git a/docs/faq/install.txt b/docs/faq/install.txt index 810247a1bc..492cc082f1 100644 --- a/docs/faq/install.txt +++ b/docs/faq/install.txt @@ -53,7 +53,7 @@ own version requirements. Over the next year or two Django will begin dropping support for older Python versions as part of a migration which will end with Django running on Python 3 -(see below for details). +(see below for details). All else being equal, we recommend that you use the latest 2.x release (currently Python 2.6). This will let you take advantage of the numerous @@ -92,11 +92,13 @@ See our `Django-friendly Web hosts`_ page. .. _`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 -checking in broken code. We use the development code (from the Subversion -repository) directly on our servers, so we consider it stable. With that in -mind, we recommend that you use the latest development code, because it -generally contains more features and fewer bugs than the "official" releases. +Generally, if you're using code in production, you should be using a +stable release. The Django project publishes a full stable release +every nine months or so, with bugfix updates in between. These stable +releases contain the API that is covered by our backwards +compatibility guarantees; if you write code against stable releases, +you shouldn't have any problems upgrading when the next official +version is released. diff --git a/docs/internals/release-process.txt b/docs/internals/release-process.txt index e990ab8ab6..20bc365844 100644 --- a/docs/internals/release-process.txt +++ b/docs/internals/release-process.txt @@ -47,7 +47,7 @@ not "months"), and will probably represent major, sweeping changes to Django. 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. .. _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.) -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 or two), the core development team will examine the landscape and announce a