outaTiME (refinn dot com)

Shortly after last week’s Django 1.0.1 release, several people noted that the packaging script used to produce the release omitted several directories from the Django source tree; mostly this affected some unit tests, but at least one of the omitted directories affected the use of Django itself (specifically, of django.contrib.gis). So tonight we’re issuing Django 1.0.2, which is built around an updated packaging script and should resolve these problems.

This is a recommended upgrade for anyone using or targeting Django 1.0 or Django 1.0.1; to obtain a copy, swing by the downloads page, and don’t forget to read the release notes. For the security conscious, a signed file containing the package’s checksums is, as always, available.

(Via The Django weblog.)

Following the previously-announced schedule, today the Django team
has released Django 1.0.1. This is a bugfix-only release containing fixes and improvements to the Django 1.0 codebase, and is a recommended upgrade for anyone using or targeting Django 1.0.

For full details, check out the 1.0.1 release notes, and to grab a copy of Django 1.0.1, visit the downloads page. For the security-conscious, a file containing checksums of the 1.0.1 package, signed with the release manager’s key, is available.

And with Thanksgiving coming up in the US, your friendly local release manager would like to pause for a moment and express thanks, on behalf of myself and the Django development team, for all the work put in by all the members of our community to help keep the releases coming, the tickets triaged and the bugs fixed. We wouldn’t be able to do it without all of you, so give yourselves a big pat on the back and see if you can’t sneak an extra slice of pie come Thanksgiving dinner.

We’ll see you again in a few months, for either Django 1.0.2 or Django 1.1. Happy holidays!

(Via The Django weblog.)

Following the previously-announced schedule, today the Django team
has released Django 1.0.1 beta 1; this is a preview of the upcoming
Django 1.0.1 release, which consists solely of bugfixes and other
improvements to the Django 1.0 codebase. This package also follows
our policy of maintaining compatibility in the 1.0 release series.

Though it’s labeled a "beta", this package is considered to be of
production quality; we’re releasing it as a preview of Django 1.0.1,
and the primary goal of this package is to give users of Django 1.0 an
idea of what’s been fixed in the codebase since the 1.0 release. If
there’s a particular issue you’re interested in which doesn’t seem
to be resolved in Django 1.0.1 beta, please consider helping the
Django team to fix it by working to develop a patch (see the
contribution guidelines for details); Django 1.0.1 is currently
scheduled for release on November 14, 2008, which provides a roughly
two-week window for submitting patches (and please keep in mind that
patches intended for inclusion in 1.0.1 should be against the 1.0.X
branch and not trunk).

As such, this release is mostly of interest to developers who want to help out with the Django development process; the final Django 1.0.1 release next month, however, will be a recommended upgrade for all users of Django 1.0.

Also, this beta release does not contain release notes, as there are
no new features, only bugfixes. When the final Django 1.0.1 release is
issued next month, a list of resolved issues since 1.0 will be
included in lieu of release notes.

For verification purposes, a file containing the MD5 and SHA1
checksums of the 1.0.1 beta package has been placed on the
djangoproject.com server. The file is PGP-signed with the Django
release manager’s key; this key has the ID 0×8C8B2AE1 and can be
obtained from, e.g., the MIT PGP keyserver.

(Via The Django weblog.)

No, you’re not hallucinating, it’s really here.

Around three years ago, Adrian, Simon, Wilson and I released some code to the
world. Our plan was to hack quietly on it for a bit, release a solid 1.0
release, and then really get the ball rolling.

Well.

What happened, of course, was that an amazing community sprung up literally
overnight — our IRC channel had over a hundred people in it the day after
release, and it’s never been that “empty” since.

I really can’t stress enough how amazing our community of users and developers
are. About half of the code that’s gone into Django over the past three years
has been contributed by someone other than a core committer. Since our last
stable release, we’ve made over 4,000 code commits, fixed more than 2,000 bugs,
and edited, added, or removed around 350,000 lines of code. We’ve also added
40,000 lines of new documentation, and greatly improved what was already there.

Django 1.0 represents a the largest milestone in Django’s development to date: a
web framework that a group of perfectionists can truly be proud of. Without this
amazing community, though, it would have never happened.

You can download Django 1.0 on the Django downloads
page, and read the complete release
notes.

For distributors and for verification purposes, a file containing the MD5 and
SHA1 checksums of the 1.0 package has been placed on the djangoproject.com
server. This file
is PGP-signed with the Django release manager’s public key. This key has the ID
0×8C8B2AE1 and can be obtained from, e.g., the MIT PGP
keyserver.

(Via The Django weblog.)

In accordance with the (updated) Django 1.0 release roadmap, today we’ve released the first release candidate for Django 1.0.

To grab a copy of the release candidate, head over to the Django downloads page, and be sure to read the release notes. Please keep in mind, though, that this release is not meant for production use, and is intended primarily for developers who are interested in checking out the new features in 1.0 and helping to identify and resolve bugs prior to the final release. The 1.0 alpha and beta releases and release candidates will not receive long-term support and will not be updated with security fixes, since their main purpose is to serve as a stepping-stone on the path to the final Django 1.0, due to be released as soon as possible..

For distributors and for verification purposes, a file containing the MD5 and SHA1 checksums of the release candidate package has been placed on the djangoproject.com server. This file is PGP-signed with the Django release manager’s public key. This key has the ID 0×8C8B2AE1 and can be obtained from, e.g., the MIT PGP keyserver.

(Via The Django weblog.)

In accordance with the (updated) Django 1.0 release roadmap, tonight we’ve released the second “beta” testing version of Django 1.0.

To grab a copy of 1.0 beta 2, head over to the Django downloads page, and be sure to read the release notes. Please keep in mind, though, that this release is not meant for production use, and is intended primarily for developers who are interested in checking out the new features in 1.0 and helping to identify and resolve bugs prior to the final release. The 1.0 alpha and beta releases will not receive long-term support and will not be updated with security fixes, since their main purpose is to serve as a stepping-stone on the path to the final Django 1.0, due to be released on September 2, 2008.

As of this release, Django is officially in a feature freeze for 1.0; from here on out, we’ll only be working on bugs and stability before the final 1.0 release. If you’d like to help out, please review our documentation for contributors and feel free to join in one of the development sprints scheduled for the run up to 1.0.

(Via The Django weblog.)

In accordance with the Django 1.0 release roadmap, tonight we’ve released the first “beta” testing version of Django 1.0.

To grab a copy of 1.0 beta 1, head over to the Django downloads page, and be sure to read the release notes. Please keep in mind, though, that this release is not meant for production use, and is intended primarily for developers who are interested in checking out the new features in 1.0 and helping to identify and resolve bugs prior to the final release. The 1.0 alpha and beta releases will not receive long-term support and will not be updated with security fixes, since their main purpose is to serve as a stepping-stone on the path to the final Django 1.0 release.

The next step on that path will be the first Django 1.0 release candidate, currently scheduled for August 21. If you’d like to help out, please review our documentation for contributors and feel free to join in one of the development sprints scheduled for the run up to 1.0; the full schedule is available in the Django 1.0 release roadmap.

(Via The Django weblog.)

In accordance with the Django 1.0 release roadmap, tonight we’ve released the second “alpha” testing version of Django 1.0.

To grab a copy of 1.0 alpha 2, head over to the Django downloads page, and be sure to read the release notes. Please keep in mind, though, that this release is not meant for production use, and is intended primarily for developers who are interested in checking out the new features in 1.0 and helping to identify and resolve bugs prior to the final release. The 1.0 alpha releases will not receive long-term support and will not be updated with security fixes, since their main purpose is to serve as a stepping-stone on the path to the final Django 1.0 release.

The next step on that path will be the Django 1.0 beta release, currently scheduled for August 14. If you’d like to help out, please review our documentation for contributors and feel free to join in one of the development sprints scheduled for the run up to 1.0; the full schedule is available in the Django 1.0 release roadmap.

(Via The Django weblog.)

Are you an ExtJS and Django user? If so, you will want to check out this article by Matt of Tangible Worldwide on Using ExtJS’s Grid Filtering with Django.

He goes into detail on how to tweak the grid filtering system that is aimed at PHP, and getting it to work in a way that allows you to write this Django code:

# take a ContentType model name (say, from the URL)
# and create a QuerySet
ctype = ContentType.objects.get(model=ctype_model)
model_class = ctype.model_class()
obj_qs = model_class.objects.filter()
 
# 'q' is the set of POSTed filtering parameters
filter_params = request.POST.get('q', '[]')
 
# decode the filtering parameters w/ simplejson
filter_params = simplejson.loads(filter_params)
 
# apply the filtering params
filtered_qs = get_queryset_from_ext_filters(obj_qs, filter_params)

ExtJS 2.1 saw inclusion of the popular (at least in my world) user extension for AJAX filtering of data by grid columns. As useful as this is (provided you can abide by the GPL or paid licensing options), the filter parameters serialized as a PHP array, which is not particularly useful for other languages. With a quick modification to the grid filtering serialization method and a helper function for Django, we can rewire the system to send a JSON string that Django can use to directly apply filtering to a QuerySet. I’ve found that most clients love having this sort of command and flexibility over their data — especially the kind that don’t necessarily realize that this visualization and control exists. I like that. Additionally, the amount of work and code required is minimal, and the code both reusable and straight-forward. I like that, too.

There are 4 steps to this process:

1. Modify the serialization method in GridFilters.js
2. Set up the helper function that will process the QuerySet with the grid filter parameters
3. Slightly customize your models (see below)
4. Add (simple) helper code to your Ajax view

(Via Ajaxian » Front Page.)