Changes between Version 87 and Version 88 of IrcFAQ

12/04/2008 09:40:02 AM (9 years ago)
Paul Bissex

Cleaned up some outdated bits


  • IrcFAQ

    v87 v88  
    3737= Installing and Deploying Django = #InstallAndDeploy
    39 == Which version should I use, the 0.96 release or the Subversion checkout? == #WhichVersion
    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.
    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.
    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.
    47 == When will the next release be out? -or- When will X branch be done? == #AreWeThereYet
    49 "When it's done" is the short answer. Fixed release dates are rarely set, but searching or browsing the developer list ( can be informative.
    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
     41"When it's done" is the short answer. Reading the [ release process documentation] is recommended if you're curious. Searching or browsing the developer list ( can also be informative.
    5343If you feel like pitching in, great! See the [ Contributing] docs.
    157147Note that there are no parentheses on `` in this version, so you're passing ''the function itself'' to be the default. When Django receives a function as a default value for a model field, it will call the function each time a new object is saved, and that will correctly generate the current date/time for each object.
    159 == I'm trying to use {{{__str__()}}} or {{{__unicode__()}}} on my model, but it's not working == #StrVsUnicode
    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__()}}}.
    163 More information on exactly what changed regarding Unicode in Django is available on the UnicodeBranch page; note the [ application porting checklist] if you're coming from an older version of Django.
    165 See the StringEncoding page for an overview of how Django handles Unicode text.
    168150= How to do Stuff =
    204186If you're using render_to_response(), you'll have to include RequestContext, as described here:
    206 If you're using 0.96, you can get the same functionality by creating a template context processor, as described:
     188If you're using 0.96 or later, you can get the same functionality by creating a template context processor, as described:
Back to Top