The Wayback Machine - https://web.archive.org/web/20110315154817/http://www.djangoproject.com:80/weblog/

Weblog

Latest entries

Django 1.3 release candidate available

We're almost there!

Tonight we've issued the first release candidate for Django 1.3. Barring major issues discovered with this package, the final Django 1.3 release will follow a little over a week from now, most likely being released in Atlanta at PyCon US 2011.

For the impatient, you can download the release candidate package here (and get the checksums for it here), but there are a couple of things worth noting:

  • As with all pre-release versions of Django, this is not intended for production use; the purpose of this release candidate is to identify any major issues which could or should block the final 1.3 release.
  • As this is a release candidate, it does not have standalone release notes. Instead, please refer to the draft 1.3 release notes, which will be used to produce the notes accompanying the final 1.3 release. If you notice something missing from those notes, please file a ticket in Django's Trac (see below) as soon as possible.

Note regarding translations

At this point, Django 1.3 is in feature freeze (and has been since the 1.3 beta release), as well as translation string freeze; between now and the final release, no new strings or changes to existing strings will be accepted. Translators are encouraged to submit their final translations as quickly as they can. Interested parties can track the progress of Django's translations on the 1.3 status page at Transifex.

Additionally, we are still seeking translation coordinators for the following languages:

  • bg (Bulgarian)
  • cy (Welsh)
  • fy_NL (Frisian)
  • gl (Galician)
  • hi (Hindi)
  • is (Icelandic)
  • km (Khmer)
  • kn (Kannada)
  • ko (Korean)
  • lt (Lithuanian)
  • mk (Macedonian)
  • ta (Tamil)
  • vi (Vietnamese)

If you're interested in becoming a translation coordinator for one of these languages, you can sign up and join the Django translation project at Transifex.

Python version compatibility

The release of Django 1.2 was notable for being the first to change our policy toward Python version compatibility; 1.2 dropped support for Python 2.3, establishing Django's support as Python 2.4 and higher (within the 2.X series).

Django 1.3 will not drop support for Python 2.4; however, it is exceedingly likely that Django 1.3 will be the final release of Django to support Python 2.4, and that Django 1.4 will require a minimum of Python 2.5. A final decision on this matter will be reached next week at PyCon, and that decision will be announced with the Django 1.3 final release notes.

It is expected that a document detailing Django's Python 2.x deprecation process, and timeline for moving to Python 3.x, will be made available concurrently with, or shortly after, the Django 1.3 release.

How you can (still) help with Django 1.3

As always, we wouldn't be able to produce Django without the help of the community. And even at this late stage in the release process, we still need and greatly value any contributions you can make.

Since Django 1.3 is now at the release-candidate stage, we are actively soliciting reports of blocking issues which could prevent the final release; as such, we encourage as many users as are able to download and test (in a non-production environment) tonight's release candidate package.

If you spot a bug, please swing by Django's Trac instance, search to see if it's been reported, and if not report it as a new ticket.

Additionally, over the next week we will be finalizing the Django 1.3 documentation and translations. If you've got documentation you'd like to see land in the final 1.3 release, please open a ticket with a documentation patch, or -- for existing tickets -- bring it up on the django-developers mailing list. If you can contribute to one of Django's translations, please join the Django translation project at Transifex to do so.

And if all goes well, we'll be back here again in a week for the final Django 1.3 release, live from PyCon in Atlanta.

Posted by James Bennett on March 3, 2011

Django 1.3 release schedule - Update 4

According to our most recent release schedule, we should have published our release candidate this week. However, this hasn't happened.

This is mostly due to last week's security release. Preparing a security release has diverted resources that would have otherwise been used to work on the release candidate. In addition, the act of putting out a release candidate has increased the number of eyeballs on the code, which resulted in a number of new release-blocking issue reports. These issues have (with one exception) been resolved, but this does mean that we're not as far along as we had hoped.

Therefore, we're going to push the release by another week. This should allow us to resolve the blocker issues, and clear some more of the Ready For Checkin tickets. We are now aiming to produce a release candidate late in the week of February 21, with a final release late in the week of February 28.

As always, any and all assistance is most welcome. Test out the backwards compatibility of the trunk code, try out new features, review patches, edit documentation -- the more assistance we get, the better 1.3 will be.

Posted by Russell Keith-Magee on February 16, 2011

Errata for yesterday's security release announcement

Yesterday, we announced a security release to address a number of issues that had been brought to our attention. However, that announcement contained one error, and one omission.

Firstly, the error: the example given in the blog entry was misleading. The sample JavaScript code will work for users of Django 1.1.4, but not for users of Django 1.2.5 or trunk. If you are using trunk or Django 1.2.5, you will need to use slightly different Javascript code to extract the CSRF token from a cookie. Django's documentation for CSRF handling contains the correct examples (see the 1.1, 1.2 and trunk documentation respectively).

Secondly, the omission: we neglected to mention that the 1.2.5 release contains three other minor backwards incompatibilities. These incompatibilities relate to the process of deleting files stored in a FileField, the interpretation of initial SQL during testing, and a change to the internals of admin list_filter validation introduced in Django 1.2.4. We generally go to extraordinary lengths to avoid backwards incompatibilities of any kind, but in the case of these three changes, it was not possible to resolve bugs while preserving full backwards compatibility. For more details, see the 1.2.5 release notes.

We deeply apologize for any inconvenience caused by these errors.

Posted by Russell Keith-Magee on February 10, 2011

Security releases issued

Today the Django team is issuing multiple releases -- Django 1.2.5 and Django 1.1.4 -- to remedy three security issues reported to us. All users of affected versions of Django are urged to upgrade immediately.

Flaw in CSRF handling

Django includes a CSRF-protection mechanism, which makes use of a token inserted into outgoing forms. Middleware then checks for the token's presence on form submission, and validates it.

Previously, however, our CSRF protection made an exception for AJAX requests, on the following basis:

  1. Many AJAX toolkits add an X-Requested-With header when using XMLHttpRequest.
  2. Browsers have strict same-origin policies regarding XMLHttpRequest.
  3. In the context of a browser, the only way that a custom header of this nature can be added is with XMLHttpRequest.

Therefore, for ease of use, we did not apply CSRF checks to requests that appeared to be AJAX on the basis of the X-Requested-With header. The Ruby on Rails web framework had a similar exemption.

Recently, engineers at Google made members of the Ruby on Rails development team aware of a combination of browser plugins and redirects which can allow an attacker to provide custom HTTP headers on a request to any website. This can allow a forged request to appear to be an AJAX request, thereby defeating CSRF protection which trusts the same-origin nature of AJAX requests.

Michael Koziarski of the Rails team brought this to our attention, and we were able to produce a proof-of-concept demonstrating the same vulnerability in Django's CSRF handling.

To remedy this, Django will now apply full CSRF validation to all requests, regardless of apparent AJAX origin. This is technically backwards-incompatible, but the security risks have been judged to outweigh the compatibility concerns in this case.

Additionally, Django will now accept the CSRF token in the custom HTTP header X-CSRFTOKEN, as well as in the form submission itself, for ease of use with popular JavaScript toolkits which allow insertion of custom headers into all AJAX requests.

The following example using the jQuery JavaScript toolkit demonstrates this; the call to jQuery's ajaxSetup will cause all AJAX requests to send back the CSRF token in the custom X-CSRFTOKEN header:

$.ajaxSetup({
        beforeSend: function(xhr, settings) {
            if (!(/^http:.*/.test(settings.url) || /^https:.*/.test(settings.url))) {
                // Only send the token to relative URLs i.e. locally.
                xhr.setRequestHeader("X-CSRFToken",
                                     $("#csrfmiddlewaretoken").val());
            }
        }
    });

For reference, the Ruby on Rails team's announcement regarding this issue may be viewed here.

Potential XSS in file field rendering

Django's form system includes form fields and widgets for performing file uploads; in rendering these fields, the name of the file currently stored in the field is displayed. In the process of rendering, the filename is displayed without being escaped, as reported by Trac user "e.generalov".

In many cases this does not result in a cross-site-scripting vulnerability, as file-storage backends can and are encouraged to (and the default backends provided with Django do) sanitize the supplied filename according to their requirements. However, the risk of a vulnerability appearing in a backend which does not sanitize, or which performs insufficient sanitization, is such that Django will now automatically escape filenames in form rendering.

Directory-traversal vulnerability on Windows

Django's file-based session-storage backend stores session data in a file named with the session key. This backend validates that the key submitted in the session cookie does not contain the filesystem path separator character, as specified by Python's os.path.sep, and if that character is found in the key an exception is raised.

As mentioned in a report to the Django team by Paul McMillan, however, this is insufficient on Windows, as filesystem operations on Windows accept multiple potential path separators (os.path.sep for Windows is the backslash character; the forward slash character is also accepted). Due to other verification mechanisms -- sessions are also stored with a hash of their contents, and the hash is verified on session deserialization -- this does not automatically allow arbitrary loading or execution of files. However, due to the possibility of session replays, or more serious vulnerabilities if an attacker manages to defeat the session verification, the file-based session backend will now use an explicit whitelist of characters which may appear in session keys. This whitelist excludes all valid path separators.

Affected versions

All three of the issues described above are present in the following currently-supported Django versions:

  • Django development trunk
  • Django 1.2
  • Django 1.1

Resolution

Patches have been applied to Django trunk, and to the 1.2 and 1.1 release branches, which resolve the issues described above. The patches may be obtained directly from the following changesets:

  • Django trunk: 15464 for the CSRF issue, 15470 for the file field issue and 15467 for the file-storage issue.
  • Django 1.2: 15465 for the CSRF issue, 15471 for the file field issue and 15468 for the file-storage issue.
  • Django 1.1: 15466 for the CSRF issue, 15472 for the file field issue and 15469 for the file-storage issue.

The following new releases have been issued:

As Django trunk is currently in a beta state, users are strongly advised not to be running production deployments from it; if you are currently doing so, however, you are urged to upgrade immediately to the latest trunk, which contains patches for these issues.

General notes regarding security

As always, we ask that potential security issues be reported via private email to security@djangoproject.com, and not via Django's Trac instance or the django-developers list.

If you are or represent a third-party distributor of Django and did not receive a notification email regarding this announcement from the Django release manager, please contact james@b-list.org.

Posted by James Bennett on February 8, 2011

Django 1.3 release schedule - Update 3

According to our release schedule, this week should have seen the release of Django 1.3 final. Obviously, this hasn't happened.

The good news is that at this time, there are no tickets blocking a release. To the best of our knowledge, Django's trunk repository is currently free of regressions, there are no bugs causing serious data loss, and there are no major problems with new features. There is one ticket (#15149) that might turn into a release blocker, but is still undergoing triage. This means we're almost in a position to produce a final release.

However, in order to make Django 1.3 as good as it can be, we're going to keep the release open for a couple more weeks. This will allow us to clear out the backlog of patches that have been reviewed and are marked Ready For Checkin. There are currently 29 tickets in the Ready For Checkin state. The aim is to commit as many of these patches as time allows. If you have a ticket that is on Milestone 1.3 and you want to see it actually get committed to 1.3, then you need to get it reviewed by someone so it can progress to Ready For Checkin. If it isn't Ready For Checkin, it won't be checked in!

We have also just completed migrating Django's translation infrastructure to Transifex. This requires the existing translation teams to register on the new service. If you are involved in a translation team, make sure you have registered on Transifex so you are ready when the release candidate string freeze occurs.

With these factors in mind, we have revised the release schedule: we are now aiming to produce a release candidate in the week of February 14, with a final release in the week of February 21.

As always, any and all assistance is most welcome. Test out the backwards compatibility of the trunk code, try out new features, review patches, edit documentation -- the more assistance we get, the better 1.3 will be.

Posted by Russell Keith-Magee on February 2, 2011

DjangoCon Europe 2011 announced

The DjangoCon Europe 2011 organizing committee, chaired by Remco Wendt, has just announced that DjangoCon Europe 2011 will be held in Amsterdam, the Netherlands, from June 6-10 2011. The conference itself will take place on June 6-8, the sprint days will be June 9-10. Though the word was already put out on twitter, the announcement is now available on the official site, http://www.djangocon.eu.

The conference venue is a former warehouse, part of the old port of Amsterdam. The sprint location is a place called "De Waag" which is an old castle in the very heart of Amsterdam, and is famous for housing the Amsterdam Guild of Surgeons during the 17th century.

The sprint location will be open for us 48-hours non stop, meaning literally that we can sprint until we drop.

Hope to see you in Amsterdam in June!

Posted by Russell Keith-Magee on January 14, 2011

Django 1.3 release schedule - Update 2

The first major task in ensuring a timely Django 1.3 release has been completed: the backlog of unreviewed tickets has been cleared. As of the time of writing, every ticket in Django's ticket tracker has undergone at least an initial review.

As a result, we can now give our first report on progress towards the 1.3 release. At the time of writing, there are 20 tickets known to be release blockers; for an up-to-date list, check this Trac query.

To be considered a release blocker, a ticket must describe a problem that:

  • is a regression in behavior from Django 1.2; or
  • demonstrates a design flow or bug in a feature added in Django 1.3; or
  • reveals a problem in Django's packaging or release procedures; or
  • can cause catastrophic and unintentional loss of data under easily reproducible circumstances.

Everything else is nice-to-have, but will not prevent us from releasing Django 1.3 on schedule.

The good news is that most of the release blocking tickets are relatively minor issues. They are either regressions that have occurred due to inadequate test coverage, or relatively minor oversights in features added in 1.3. As a result, we appear to be on schedule for an on-time release (i.e., release candidate in the week of January 24, Final in the week of January 31)

Once the release blocking tickets have been addressed, attention will turn to tickets that are Ready For Checkin. Ideally, there will be no Ready for Checkin bug fixes when we make the final 1.3 release -- all tickets in the Ready For Checkin queue will hopefully either be checked in, bumped back to Accepted because the proposed patch is flawed, or represent a feature than needs to wait for the 1.4 release cycle. We will reassess the Zero-RFC goal as we get closer to the release candidate deadline.

It's important to note that a ticket marked Milestone 1.3 is not automatically guaranteed to be part of the 1.3 release. If you have a ticket that is on Milestone 1.3 and you want to see it actually get committed to 1.3, then you need to get it reviewed by someone so it can progress to Ready For Checkin. If it isn't Ready For Checkin, it won't be checked in!

There's plenty to do if you want to help out:

  • Write a patch for a release blocking bug
  • Review someone else's 1.3 Milestone ticket
  • Write a patch for a 1.3 Milestone ticket (and get someone else to review it)
  • Proof read the documentation for errors, omissions, and typos
  • Run your own sites against trunk and report any regressions or problems
  • Try using new features and report any problems you encounter

The more help we get, the better the 1.3 release will be.

Posted by Russell Keith-Magee on January 5, 2011

Django 1.3 beta 1 released

As part of the Django 1.3 release process, tonight we've released Django 1.3 beta 1, a preview/testing package that gives a little taste of some of the new features coming in Django 1.3. As with all alpha and beta packages, this is not for production use, but if you'd like to try out some of the new goodies coming in 1.3, or if you'd like to pitch in and help us fix bugs before the final 1.3 release (due in January), feel free to grab a copy and give it a spin.

Also, note that this beta release contains the patches mentioned in the security announcement earlier today. If you're using Django 1.3 alpha 1, you're urged to upgrade to beta 1 or apply the trunk patches immediately.

You can get a copy of the 1.3 beta package from our downloads page, and we recommend you read the release notes. Also, for the security conscious, signed MD5 and SHA1 checksums of the 1.3 beta package are available.

Posted by James Bennett on December 22, 2010

Security releases issued

Today the Django team is issuing multiple releases -- Django 1.2.4, Django 1.1.3 and Django 1.3 beta 1 -- to remedy two security issues reported to us. All users of affected versions of Django are urged to upgrade immediately.

Information leakage in Django administrative interface

The Django administrative interface, django.contrib.admin, supports filtering of displayed lists of objects by fields on the corresponding models, including across database-level relationships. This is implemented by passing lookup arguments in the querystring portion of the URL, and options on the ModelAdmin class allow developers to specify particular fields or relationships which will generate automatic links for filtering.

One historically-undocumented and -unofficially-supported feature has been the ability for a user with sufficient knowledge of a model's structure and the format of these lookup arguments to invent useful new filters on the fly by manipulating the querystring.

As reported to us by Adam Baldwin, however, this can be abused to gain access to information outside of an admin user's permissions; for example, an attacker with access to the admin and sufficient knowledge of model structure and relations could construct querystrings which -- with repeated use of regular-expression lookups supported by the Django database API -- expose sensitive information such as users' password hashes.

To remedy this, django.contrib.admin will now validate that querystring lookup arguments either specify only fields on the model being viewed, or cross relations which have been explicitly whitelisted by the application developer using the pre-existing mechanism mentioned above. This is backwards-incompatible for any users relying on the prior ability to insert arbitrary lookups, but as this "feature" was never documented or supported, we do not consider it to be an issue for our API-stability policy. The release notes for Django 1.3 beta 1 -- which will include this change -- will, however, note this difference from previous Django releases.

Denial-of-service attack in password-reset mechanism

Django's bundled authentication framework, django.contrib.auth, offers views which allow users to reset a forgotten password. The reset mechanism involves generating a one-time token composed from the user's ID, the timestamp of the reset request converted to a base36 integer, and a hash derived from the user's current password hash (which will change once the reset is complete, thus invalidating the token).

The code which verifies this token, however, does not validate the length of the supplied base36 timestamp before attempting to convert it. An attacker with sufficient knowledge of a site's URL configuration and the manner in which the reset token is constructed can, then, craft a request containing an arbitrarily-large (up to the web server's maximum supported URL length) base36 integer, which Django will blindly attempt to convert back into a timestamp.

As reported to us by Paul McMillan, the time required to attempt this conversion on ever-larger numbers will consume significant server resources, and many such simultaneous requests will result in an effective denial-of-service attack. Further investigation revealed that the password-reset code blindly converts base36 in multiple places.

To remedy this, the base36_to_int() function in django.utils.http will now validate the length of its input; on input longer than 13 digits (sufficient to base36-encode any 64-bit integer), it will now raise ValueError. Additionally, the default URL patterns for django.contrib.auth will now enforce a maximum length on the relevant parameters.

Affected versions

Both of the issues described above are present in the following currently-supported Django versions:

  • Django development trunk
  • Django 1.2
  • Django 1.1

Resolution

Patches have been applied to Django trunk, and to the 1.2 and 1.1 release branches, which resolve both issues described above. The patches may be obtained directly from the appropriate changesets:

The following new releases have been issued:

Django 1.3 beta 1, which will contain the patch from Django trunk, will also be issued later today.

General notes regarding security

As always, we ask that potential security issues be reported via private email to security@djangoproject.com, and not via Django's Trac instance or the django-developers list

Due to the impending Christmas and New Year's holiday, our normal process of notifying distributors of Django one week in advance of security-releated release was shortened somewhat to allow these releases to be issued before most Django users take their holiday vacations.

If you are or represent a third-party distributor of Django and did not receive a notification email from the Django release manager, please contact james@b-list.org.

Posted by James Bennett on December 22, 2010

Django 1.3 release schedule -- Update

Once again, astute observers will have noted a missed deadline: November 29 has come and gone, but Django 1.3 beta 1 hasn't been released.

In this case, the delay has been caused by a desire to deliver on everything that has been discussed over the last few months. The release of Beta 1 marks the full feature freeze for Django 1.3, and there are lots of little features that have been discussed at length, and are very close to completion, but haven't been committed to trunk. Rather than defer these features to the 1.4, we've opted to push the release schedule by a couple of weeks to let the last few commits happen.

At this point, the outstanding issues are:

  • #7817: Modification of the {% with %} to support multiple assignment
  • #9456: Modification of the {% include %} tag to support subtemplate assignment
  • #11675: Addition of a pylibmc cache backend
  • #14844: dealing with pluralization rules in {% blocktrans %}
  • Some administrative i18n issues, aimed at allowing translators to use Transifex to keep translations up to date

In order to accommodate these last features, we've decided to push the Beta 1 release until December 21.

To ensure that we have enough time for fixing bugs once the beta has been released, we're also going to push the final release date by 2 weeks. This means the 1.3 release candidate should be released on January 24, followed by a final 1.3 release on January 31.

Once the beta has been released, we will be focussing on bug fixes. We will be using the Ready For Checkin list as the working list, so if you have a bug you want to see fixed, make sure it has been reviewed and is correctly tagged for as being ready for checkin. We also need assistance triaging the list of unreviewed tickets.

If you're not sure what you need to do in order to get your ticket ready for checkin, read the contribution guide; we also have a work-in-progress HowTo guide that may help clarify what is needed. If you're still not sure, try asking on the #django-dev IRC channel for a push in the right direction.

Posted by Russell Keith-Magee on December 13, 2010

DjangoCon US 2011 announced!

The DjangoCon organizing committee, led by Steve Holden, has just announced that DjangoCon US 2011 will be held in Portland, Oregon, from September 6-8 2011. This will be followed by a couple of days of sprints. We are also exploring the possibility of running tutorials on the day before (September 5).

There will be a change of venue from the last two years -- we've shifted to the Hilton Portland and Executive Tower. This is located right in the middle of downtown Portland, so it should be a lot more convenient for dinner and other social activities.

The budget hasn't been finalized yet, but we will be aiming to keep registration fees comparable to DjangoCon US 2010. However, we have already negotiated complimentary internet for everyone staying at the hotel, and throughout the ballroom where the conference will be taking place.

Although there was some interest in looking at other venues, due to the relatively short time frame, it was necessary to stick to Portland for at least one more year. To that end -- if you are interested in hosting DjangoCon US 2012 in a location other than Portland, now is the time to start organizing. Jump on the DjangoCon organizers mailing list an let us know that you want to help out. And if you want to help organize DjangoCon US 2011, jump on the same list!

Hope to see you in Portland in September!

Posted by Russell Keith-Magee on November 22, 2010

Upcoming development sprints

In order to assist in the timely release of Django 1.3, we are holding a series of Django development sprints over the next couple of weeks.

This weekend, on Saturday November 13, there will be 2 sprints held in parallel. One sprint will be held at the betahaus coworking space in Berlin, Germany. The second will be at several locations around Argentina.

In three weeks time there will be another sprint -- this time, a 2 day sprint (December 4 and 5), held in Sydney, Australia. This sprint will be hosted by The Interaction Consortium.

If you can't make it to Argentina, Berlin, or Sydney in person, you can join us in the #django-sprint IRC channel and help out that way.

For more information on the plans for these sprints, please check out the wiki pages. If you plan on attending, please add your name to the list so that the organizers know how many people to expect. If you want to know what to work on, or you've never been sprinting before and want to know what to expect, check out the wiki page on ideas for sprints.

Hope to see you there!

Posted by Russell Keith-Magee on November 11, 2010

Django 1.3 alpha 1 released

As part of the Django 1.3 release process, tonight we've released Django 1.3 alpha 1, a preview/testing package that gives a little taste of some of the new features coming in Django 1.3. As with all alpha and beta packages, this is not for production use, but if you'd like to try out some of the new goodies coming in 1.3, or if you'd like to pitch in and help us fix bugs before the final 1.3 release (due in January), feel free to grab a copy and give it a spin.

You can get a copy of the 1.3 alpha package from our downloads page, and we recommend you read the release notes. Also, for the security conscious, signed MD5 and SHA1 checksums of the 1.3 alpha package are available.

Posted by James Bennett on November 11, 2010

Django 1.3 alpha 1 -- Update

Astute observers will have noted that October 18 has come and gone, but Django 1.3 alpha 1 hasn't been released.

There are two reasons for this. Firstly, we landed a number of big features very close to the original planned release date, including class-based views, a static media framework, and a context manager for transactions. However, we're still seeing some sporadic bug reports for these features. We don't expect that the alpha will be bug-free, but we'd like to avoid cutting a release with any completely boneheaded mistakes in it, so we're going to wait a little bit for the dust to settle before we produce the alpha.

Secondly, James Bennett, our release manager, has been particularly busy of late, and hasn't been in a position to turn the crank handle that makes the release. Although our bus factor for making releases is low, it is greater than 1 -- if James is unable to find time to make the release once the time comes, there are a couple of other people on the core team (including myself and Jacob) that know how to produce a release should the need arise.

This delay only affects the alpha -- it doesn't change the overall schedule. With any luck, we should have an alpha by this time next week. After that, we're still targeting a beta (and full feature freeze) at the end of November, and a final release for January 17 next year. If you have a little feature that you want to see in Django 1.3, now is the time to make sure the your patch is in good condition, and join us on the Django-developers mailing list or on #django-dev on IRC to advocate for the features your want to see.

Posted by Russell Keith-Magee on October 25, 2010

Django 1.3 release schedule

Django 1.2 has been in the wild for a couple of months, and we've had plenty of time to talk about what we want to see in Django 1.3. That means it's time to pick features and nominate some deadlines.

From the feedback from DjangoCon, and from conversations on the mailing lists and IRC, it's fairly clear that people are happy with the new features that have been added with Django 1.1 and 1.2. However, there is also concern about the growing backlog of bugs and minor feature requests that have accrued while we work on these big features.

For this reason, Django 1.3 is going to be light on big new features, and heavy on bugfixes and little features. We'll still have a couple of big features -- most likely those features that have missed previous release, such as logging and class-based generic views. However, for the bulk of the release, we're going to try and focus on getting the open ticket count down.

Here's the release schedule:

  • October 18, 2010 -- Django 1.3 alpha; major feature freeze
  • November 29, 2010 -- Django 1.3 beta; complete feature freeze
  • January 10, 2011 -- Django 1.3 RC1; translation string freeze
  • January 17, 2011 -- Django 1.3 final

Full details, an explanation of the schedule, and suggestions on how to help out can be found in the 1.3 Roadmap.

So dig in! There's plenty of work to do, and the more volunteers we have, the better Django 1.3 will be!

Posted by Russell Keith-Magee on September 30, 2010

Archives

RSS feeds