39 | | == Which version should I use, the 0.96 release or the Subversion checkout? == #WhichVersion |
40 | | |
41 | | The 0.96 release is well-tested and stable, and is best for production deployments. Tracking the development version of Django through a Subversion checkout can be nice if there's a new feature you really want, but does require you to pay more attention to what's going on in Django development -- if a backwards-incompatible change is introduced, you'll need to be watching the development timeline to notice it and change your code to suit, where sticking to official releases means that you get a list of any changes you need to make in the release notes. |
42 | | |
43 | | All backwards incompatible changes are (or should be) also recorded on the BackwardsIncompatibleChanges wiki page. Let us know (file a ticket) if you notice any genuine backwards incompatibilities that are missing. |
44 | | |
45 | | There will be several backwards-incompatible changes before the next release of Django (for example, the workings of the admin app will be changing), so it's officially recommended that production deployments stick to the 0.96 release until the next release is ready. |
46 | | |
47 | | == When will the next release be out? -or- When will X branch be done? == #AreWeThereYet |
48 | | |
49 | | "When it's done" is the short answer. Fixed release dates are rarely set, but searching or browsing the developer list (http://groups.google.com/group/django-developers/) can be informative. |
50 | | |
51 | | The status and roadmap of Django's path to 1.0 can be found on the VersionOneRoadmap. The VersionOneFeatures page might be helpful also. |
| 39 | == When will the next release be out? -or- When will feature X be done? == #AreWeThereYet |
| 40 | |
| 41 | "When it's done" is the short answer. Reading the [http://docs.djangoproject.com/en/dev/internals/release-process/ release process documentation] is recommended if you're curious. Searching or browsing the developer list (http://groups.google.com/group/django-developers/) can also be informative. |
159 | | == I'm trying to use {{{__str__()}}} or {{{__unicode__()}}} on my model, but it's not working == #StrVsUnicode |
160 | | |
161 | | It's likely that you're using {{{__str__()}}} with the development version of Django, or {{{__unicode__()}}} with a release version. After the release of 0.96, Django's internals became fully Unicode aware. As a result, model classes that used to use {{{__str__()}}} to provide string versions of themselves need to be updated to use {{{__unicode__()}}} to work with the development version of Django. However, users of a Django release still need to use {{{__str__()}}}. |
162 | | |
163 | | More information on exactly what changed regarding Unicode in Django is available on the UnicodeBranch page; note the [http://code.djangoproject.com/wiki/UnicodeBranch#PortingApplicationsTheQuickChecklist application porting checklist] if you're coming from an older version of Django. |
164 | | |
165 | | See the StringEncoding page for an overview of how Django handles Unicode text. |
166 | | |