As to the discussion. From where I’m standing it seems like Django developers are hold off by a common disease among programmers – perfection. On one side it is very useful to have someone to look at every detail, but on the other hand, it sometimes gets excrutiantly slow to do anything at all.

Having that in mind I see only two directions in which Django team can go:
1) You remain status quo and pretend that nothing is wrong. You take your time and release 1.0 in a matter of 3 months perhaps.
2) You get over yourself, release 0.97 as it is now and gradually go for the 1.0 grand release.

It may seem like it’s just pure nonsense to release just because you can, but if people are already using trunks in production as opposed to release versions, why not make it easier for those few which actually care and want to contribute documentation and add-ons to the project?

As it was said before, who knows when the goals for 1.0 will be achieved, it could be those 3 months or it could be as long as 6 months. And that in a software world is eternity. Think about it.

Cheers!

I would really really love more frequent updates. I just can’t run off of svn but would love some of the features.

There’s another good reason to have frequent releases. It communicates to people who are evaluating Django that the project is alive and thriving and gets them excited to use it and join the community. This turns into a self feeding cycle where the buzz grows and grows.

Switch to a development model and toolset that facilities frequent releases. You can use bzr and keep different branches of your code locally (and bzr’s shelf plugin for when you want to return to head for a little while and then resume working on your branch). This will enable you to create regularly scheduled releases and still work on tasks that take longer to accomplish than one release cycle allows.

Scheduling a release for every 4 months would give you three per year. The last two weeks could be for testing and code would be frozen.

(btw, you don’t have to give up trac to use bzr, since bzr can be used as a frontend for svn)

This is something I’ve argued for for quite a while. A great example is the “Queryset Refactor” branch which was in the works for many many months, and a lot of Django’s “core” features are like this. There is a lot of functionality that truly is needed by people like myself, people who aren’t writing very basic blog software, or who are writing software that needs to scale in very typical situations. While some of the stuff I/we do may be edge cases, I’ve found through discussion that a lot of it is quite common.

After a lot of experience with patching Django, I for one can say it is NOT fun having to branch off, and it’s not something I want to ever do on any current or new projects. But when you have so many people willing to fix the current issues, and then very few who seem to be “allowed” to fix them, nothing ever happens. This presently has made me consider moving away from Django as we already have switched away from it’s template engine, and the ORM limitations and lack of updates make it very difficult to complete some projects.

A lot of people may disagree with me, but that’s their right. Django is a very nice framework, and I believe it’s one of the better frameworks out there. Can it be used for every project? Not if you don’t want to deal with headaches.

I for one will continue to use Django, on any project I can, as I very much enjoy using Python. But if a project needs to perform well, and I have the slightest doubt Django can’t perform in that situation, I’m not even going to think of recommending it.

The big pro about open development is you can just kick in and devote your time to develop the project. You will have a voice, you can influence development and planning, and after all you can speed things up.

Constructive criticism is indispensable, it’s the community’s obligation. But it should not annoy you if things do not strictly follow your expectations.

I hope I can talk you into turning some of your energy towards helping us get 1.0 out as soon as possible. I’ve posted a proposed roadmap on django-dev (http://groups.google.com/group/django-developers/browse_thread/thread/5ce124e7526dad); I’d especially like to see your feedback.