> Let's get a definitive list of features we want in Django 1.0, and
> let's release it.

> I'll start with a proposed list, which no doubt has omissions. But
> first, here's a proposal for how to handle this:

>     1. We decide on the list of features/changes.

>     1.5. Once the list is final, we do NOT add to it except in case of
> an Act of God.

>     2. We set a deadline.

>     3. We work -- *primarily* on the list of features/changes, but
> allowing some time for squeezing in any other small fixes that we have
> time for.

>     4. Any feature that's not implemented by the deadline does NOT
> make it into version 1.0. But fear not, because version 1.0 is not the
> end of Django -- it's only the beginning!

>     5. Release, rejoice.

> The first order of business is deciding the features/changes. I'll
> kick it off with the list I've been keeping.

> This is just my own list, of course, and I'm sure other
> committers/contributors have other stuff. Please contribute! Just one
> important thing to note: This list is for Big Stuff only. Do not
> suggest features that would be able to be added/changed *after* the
> 1.0 release in a backwards-compatible way. The goal here is to have a
> simple, concrete list of major things that need to be done to the
> framework -- not a list of 4,000 tiny things.

> Without further ado, here's my list:

> * newforms-admin
> * queryset-refactor
> * django.newforms becomes django.forms
> * Model-level validation
> * Change django.templatetags not to use __path__ hacking
> * #3591 -- Make INSTALLED_APPS an instance, and each app an instance
> * #5361 -- File storage refactoring
> * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff

> What am I forgetting?

> And, finally, a bit of a controversial statement, but...

> I think we ought to call the release 2.0.

> Jacob and I have talked in the past about how we should've called
> magic-removal version 1.0. (This ended up being 0.95.) For all intents
> and purposes, it *was* 1.0 in spirit -- it was the first major
> refactoring of several parts of the framework, and it was a point for
> me personally where I started to feel like an acceptable number of the
> legacy warts from pre-open-sourcing had been removed.

> So, that's one reason: philosophically, conceptually, in our minds, in
> our hearts, we're really dealing with a 2.0 product. We know Django
> rocks (and is rock-solid), and we should give it an appropriate
> number.

> My second reason for choosing 2.0 is, shall we say, less wholesome.
> After having endured a 2.5+ year deluge of "When is 1.0 coming out?"
> blog entries, comments, e-mails and in-person confrontations from
> people all around the world, I would find it incredibly satisfying, in
> a devilish way, to release this thing and slap a "2.0" on it. It would
> underscore the project's stability while at the same time
> demonstrating that version numbers are completely arbitrary.

> It'd be like Google's IPO price, which was set to the mathematical
> constant "e" -- a "we're not playing by your rules" message to Wall
> Street.

> Something to ponder!

> Adrian

> --
> Adrian Holovaty
> holovaty.com | djangoproject.com