Django 1.7 release candidate 2
It's almost here!
Today we're pleased to announce the second release-candidate package for Django 1.7. This release has been quite a while in the making, and includes several major new features. There's a new built-in schema-migration framework, improved tools for validating and checking your projects, a complete refactor of the way Django identifies and loads your applications, and support for custom database lookups.
And that's just the biggest highlights; for a full rundown of features, see the in-development 1.7 release notes.
As with all pre-release packages, this is not for production use. But if you'd like to take some of the new features for a spin, or to help find and fix bugs (which should be reported to the issue tracker), you can grab a copy of the release-candidate package from our downloads page. And as always, signed MD5 and SHA1 checksums of the 1.7 release-candidate package are available.
Note regarding release keys
For many years, every Django package has been accompanied by signed checksums, for verification purposes; more recently, starting with the 1.6 release series, our uploads to the Python Package Index have been trying out the option to upload signed packages, and signing our release tags on GitHub.
Historically only two keys have been used for this signing; James Bennett's key, ID 0x3684C0C08C8B2AE1, and Jacob Kaplan-Moss' key, ID 0x69666DFEB00E963E. James' key is a 1024-bit DSA key, and is increasingly inappropriate for this type of use.
Moving forward, there will be two changes relevant to security-conscious users and distributors of Django:
- The list of authorized release keys is now formalized, and appears in the Django releasers file. Any key listed in that file is authorized to issue Django releases.
- James' old key has been deprecated and will no longer be used to issue releases; a new 4096-bit key, ID 0x2D9266A6808FE067, has been generated and signed by members of the core team and James' old key, and added to the releasers file. James' old key should be considered revoked for purposes of signing Django releases and security notifications. It is expected that in the not-too-distant future (likely after Django 1.7.1) that old key will also be formally revoked using a GPG revocation certificate, following a transition period of a few releases using the new key. This revocation will be publicly announced when it occurs.
Django 1.7 RC 2 is the first release using James' new key.
