Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

Fixed #12609 -- Updated FAQ on which version users should install. Th…

…anks to shanx for the report.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@13109 bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information...
commit 92983a3119d6af66b5b2099a0925092d520ee85a 1 parent ee6d552
Russell Keith-Magee authored
16  docs/faq/install.txt
@@ -53,7 +53,7 @@ own version requirements.
53 53
 
54 54
 Over the next year or two Django will begin dropping support for older Python
55 55
 versions as part of a migration which will end with Django running on Python 3
56  
-(see below for details). 
  56
+(see below for details).
57 57
 
58 58
 All else being equal, we recommend that you use the latest 2.x release
59 59
 (currently Python 2.6). This will let you take advantage of the numerous
@@ -92,11 +92,13 @@ See our `Django-friendly Web hosts`_ page.
92 92
 
93 93
 .. _`Django-friendly Web hosts`: http://code.djangoproject.com/wiki/DjangoFriendlyWebHosts
94 94
 
95  
-Should I use the official version or development version?
  95
+Should I use the stable version or development version?
96 96
 ---------------------------------------------------------
97 97
 
98  
-The Django developers improve Django every day and are pretty good about not
99  
-checking in broken code. We use the development code (from the Subversion
100  
-repository) directly on our servers, so we consider it stable. With that in
101  
-mind, we recommend that you use the latest development code, because it
102  
-generally contains more features and fewer bugs than the "official" releases.
  98
+Generally, if you're using code in production, you should be using a
  99
+stable release. The Django project publishes a full stable release
  100
+every nine months or so, with bugfix updates in between. These stable
  101
+releases contain the API that is covered by our backwards
  102
+compatibility guarantees; if you write code against stable releases,
  103
+you shouldn't have any problems upgrading when the next official
  104
+version is released.
4  docs/internals/release-process.txt
@@ -47,7 +47,7 @@ not "months"), and will probably represent major, sweeping changes to Django.
47 47
 Minor releases
48 48
 --------------
49 49
 
50  
-Minor release (1.1, 1.2, etc.) will happen roughly every six months -- see
  50
+Minor release (1.1, 1.2, etc.) will happen roughly every nine months -- see
51 51
 `release process`_, below for details.
52 52
 
53 53
 .. _internal-release-deprecation-policy:
@@ -119,7 +119,7 @@ Release process
119 119
 ===============
120 120
 
121 121
 Django uses a time-based release schedule, with minor (i.e. 1.1, 1.2, etc.)
122  
-releases every six months, or more, depending on features.
  122
+releases every nine months, or more, depending on features.
123 123
 
124 124
 After each previous release (and after a suitable cooling-off period of a week
125 125
 or two), the core development team will examine the landscape and announce a

0 notes on commit 92983a3

Please sign in to comment.
Something went wrong with that request. Please try again.