Upcoming Django releases

Posted by James Bennett on October 24, 2008

With Django 1.0 out the door and a successful inaugural DjangoCon behind us, it's time to look ahead to the future, which includes two releases:

Both of these releases, of course, will follow our policy of maintaining compatibility in the 1.0 release series.

Django 1.1 timeline

At the moment, we're aiming to release Django 1.1 on or around March 16, 2009, or roughly six months following the release of Django 1.0. As covered in our release process documentation, the 1.1 release cycle will consist of three phases: feature proposal, feature work and bugfixing/polishing. Since Django 1.1 is happening on a six-month schedule, that means two months for each phase of development; the relevant dates for 1.1 have already been discussed on the django-developers mailing list, but here's the quick breakdown (these dates are still rough estimates, and may change as needed):

March is still quite a ways off, of course, but keep in mind that the feature-proposal window will be closing in a couple of weeks; if there's something you'd really like to see in Django 1.1 and you haven't already started a discussion of it on the django-developers list, you'll want to do so quickly.

Django 1.0.1 timeline

In the much more immediate future, we're preparing to release Django 1.0.1, which will consist solely of bugfixes and similar improvements to the Django 1.0 codebase. Django 1.0.1 will be a recommended upgrade for anyone who's currently using or migrating to Django 1.0.

Because 1.0.1 will only involve bugfixes, with no feature additions to propose or test, the release process for it will be somewhat abbreviated. Here are the key dates:

From an administrative perspective, the 1.0.1 release will not involve any special categorization or milestones in the ticket tracker; with a release of this type, administrivia in Trac is far less important than simple working code, and any bug is a candidate for fixing up until the day of the release. So if there's a particular issue you'd like to see solved for 1.0.1, the best way to ensure the fix makes it into the release is to provide a working patch. As always, preferential treatment will be given to patches which match our contribution guidelines, especially to patches which include unit tests that both demonstrate the bug and demonstrate the success of the solution. Also, remember that patches for 1.0.1 should be created against the 1.0.X release branch, rather than against trunk.

Back to Top