This is a call for comments on the proposed Django 1.0 roadmap and schedule.

Note that though this is worded in the future perfect tense, it is only a draft;
I'm looking for feedback and comments from the community before the core
developers and I post a the final version of this document (which I will do
over the weekend).

What's will be in 1.0?
======================

The primary reason we've not yet released 1.0 is the long feature
wish-list. We need to balance this list of features against the need
for a timly release and speedy process. To that end, we'll categorize
all the features of 1.0 thusly:

* Must-haves: features that, if not completed, are worth delaying the
  release. That is, if the work on this list is not completed by a
  release date, we'll push the date.

  This of course means that these features are the "A" features, and we'll
  ask anyone who can help to focus on these features *first*.

* "Maybe" features: things that *should* be in 1.0 and should be worked on
  in the run up to the release. If, however, features on this list aren't
  completed, they will be dropped.

* "No" features: things that specifically will *not* be in 1.0, and which
  we'll ask developers not to focus on. We need to trim down to hit dates,
  after all.

Must-have features
------------------

1. ``newforms-admin``.

   It's clear from discussion on this list that most consider a release without
   ``newforms-admin`` to be a bad idea. Further, ``newforms-admin`` is nearly
   done; we've already started talking about merging it to trunk.

2. Replacement of ``oldforms`` throughout Django.

   Nothing in Django 1.0 should rely on the deprecated ``oldforms`` package.
   We'll need to replace ``oldforms`` usage in generic views, and in
   ``django.contrib.auth``

   ``django.contrib.comments`` still uses ``oldforms`` as well, but there's
   special situation here; see below.

3. Making Django 100% WSGI compliant.

   This simply involves fixing ticket #285. We've delayed doing this to avoid
   the backwards-incompatible change, but we must make this change before 1.0.

"Maybe" features
----------------

Again, these are features that *should* be in 1.0. In most cases, they're
actively being worked on by members of the development community and simply need
focus by committers (more about how that process will work below).

These features are arranged in *rough* order of importance.

1. Signal performance improvements (#6814).

2. Large file uploads (#2070).

3. ``INSTALLED_APPS`` refactoring (i.e. ``app()`` objects) (#3591).

4. File storage refactoring (#5361).

5. Model-level validation (#6845).

6. Full ``GenericForeignKey`` support in newforms-admin (#4667).

7. Land GeoDjango as ``django.contrib.gis``.

8. Many-to-many intermediates (#6905).

9. Fix all known bugs preventing Django from running on alternate Python
   implementations. In practice this means fixing any bugs filed before 1.0 beta
   from people working on running Django on an alternate VM.

10. De-cruftify custom template tag loading (including removing custom template
    tag ``__path__`` hacking) (#6587, etc.).

11. Better support for controlling middleware ordering (#3591).

12. Syntax for self-referencing fields in queries (#7210).

13. Finish documentation refactoring.

Features not in 1.0
-------------------

Unfortunately, the only way to get this done is to say no a lot. Let's start
now:

1. Aggregation support. Although this is a Summer of Code project that's looking
   *very* promising, the timeline for SoC won't fit with the aggressive schedule
   we're setting for 1.0. Further, it's a "dangerous" change in that it modifies
   parts of Django's query engine, and that needs to be rock-solid for a 1.0
   release.

   The good news is that it'll make a kick-ass 1.1 feature!

2. Any other additions to ``django.contrib``. Though there are many nice
   candidates out there, we simply don't have time to roll them into Django
   in time for a release. We'll come up with a "contrib process" post-1.0
   and start looking at this then.

3. Any additional database backends. Again, the overhead in integrating a new
   database backend is too much. These will need to remain external backends
   until after 1.0.

4. Any features not on this list.

   We want to ship bug-free, so we'll dedicate as much of our time to bug
   stomping as possible. This means that feature requests will need to be
   deferred.

Schedule
========

Django 1.0 will be released in early September.

The general release process will be:

* An alpha release containing all must-have features, but likely not
  bug-free. We'll push hard to have all the must-haves done in time
  for ample testing.

  The alpha release will also promote any "pending deprecation" warnings to
  full-blown deprecation warnings.

* Two beta releases.

  All "maybe" features must be completed by the first beta; after that,
  Django will enter feature freeze for about a month while we kill bugs.

* At least one -- and hopefully only one --release candidate. The candidate
  release will mark a total freeze (as well as a string freeze for
  translators); only outright bug fixes will be accepted past this point.

* A final release.

* A big fucking party.

We will hold development sprints in between each release to focus on the next
release.

Dates
-----

July 10-12      ``newforms-admin`` sprint in person at EuroPython and around
                the world in IRC.

July 18 or 19   Push to 1.0 alpha sprint in the San Francisco area, and in IRC.

July 20         **1.0 alpha.**

August 1 or 2   Push to beta sprint in Lawrence, and etc.

August 5        **1.0 beta 1.**

August 8/9      Push to beta 2 sprint, location TBA.

August 12       **1.0 beta 2.**

August 15/16    Release candidate sprint, location TBA.

August 19       **1.0 rc 1.**

August 22/23    Final release sprint, location TBA.

August 26       Earliest possible 1.0 release date, or perhaps rc2.

September 2     **1.0**

All the releases until 1.0 will be "snapshot" releases: we won't be backporting
fixes -- even security fixes -- but will just be fixing bugs in the next
release.

Process
=======

Each feature on the list (both "must-have" and "maybe") gets a "lieutenant" (to
steal of term from the Linux community) and a committer assigned. It's OK if
this is the same person, but the idea is that one committer can keep an eye and
commit from patches from a number of trusted lieutenants. In most cases, the
features on the todo list have obvious lieutenants; we'll need to assign missing
ones and also committers. I'll start putting together this list tonight; right
now it's mostly in my head.

James, as the release manager, will be in charge of keeping the schedule. He'll
keep track of who's working on what issues so that bug reports can be
efficiently routed; he'll also nag, cajole and (if necessary) berate developers
who are in danger of missing deadlines.

Once 1.0 is out we'll appoint a "version manager" (thanks for the idea, Rob).
This person will be responsible for maintaining the 1.0 release series, which
means backporting security fixes and "important" bugs and releasing 1.0.1, etc.

Similarly, as soon as we have a volunteer we'll appoint a 0.96 version manger
who will do the same with 0.96. We'll continue to support 0.96 until 1.1 ships.

With the 1.0 release, however, we will stop support 0.95 and earlier. This is
somewhat flexible; if someone has a stake in one of those older versions we'll
happily let them continue to maintain those releases, but if nobody steps up the
core team won't be able to do it.

--------------------------------------------

Comments are, of course, highly welcome. Fire away.

Jacob

On Thu, Jun 12, 2008 at 10:03 AM, Jacob Kaplan-Moss

Jacob - unless I'm going blind, you've missed out the 'below' section
that this refers to.

Russ %-)

On Wed, Jun 11, 2008 at 9:13 PM, Russell Keith-Magee

You are not blind; I, however, have mad wicked copy-paste skillz. Ahem.

On comments
-----------

``django.contrib.comments`` is a bit of special case here: ideally, Django 1.0
will ship with *no* core use of oldforms. However, refactoring the comment
system -- not just replacing forms -- is overdue, and is the subject of a Summer
of Code project.

So we'd like to deal with that situation a bit specially. I've unfortunately not
had a chance to ask Thejaswi (the student working on comments) or Jannis (his
mentor) about this, so obviously they'll need to be OK with the idea. But,
assuming this works, I'd like to do the following:

August 11 is the suggested pencils down date for GSOC. This means that if
Thejaswi is on track, he will be completed around the time of the beta 2 freeze
date. July 14 is the midterm evaluation date for Summer of Code; we should be
able to get a good idea then whether completion on schedule is likely.

If the midterm evaluation says that the project is going badly, we abandon ship
and paper over the problem by simply replacing the form components with
newforms.

If the midterm evaluation is positive -- which I expect it to be -- we work on
the assumption that it will be merged around beta 2 (or earlier, if Thejaswi has
something ready). We encourage people to push newforms-comments pretty hard,
especially during sprints.

If we get to August 11 and we don't have a newforms-comments release candidate,
we can simply release with oldforms comments: it'll be annoying but not a
deal-breaker.

This does mean newforms-comments will be a late feature to the trunk (although
only 3 weeks after the feature cutoff for other features), but if we encourage
testing in its own branch, we should be able to mitigate the risk. I would also
hope that the last 3 weeks of GSOC development would be mostly bugfixing anyway,
rather than substantial changes.

[With thanks to Russ -- the idea's originally his, and most of the
above is coppied out of something he wrote yesterday.]

Jacob

I like it, but mainly that's because I'm not the "maybe" list, and I'm
sure I can get it done in time. I do have one suggestion, though.

On Wed, Jun 11, 2008 at 10:03 PM, Jacob Kaplan-Moss

I think I know what you mean here, but "dropped" sounds an awful lot
like an all or nothing deal: either it makes it into 1.0 or it never
makes it at all. It's probably best to clarify that "dropped" just
means "dropped from 1.0, to be added in the next release after it's
completed." Yeah, it might be obvious to some of us, but a lot of
people could read it the wrong way.

-Gul

I'm curious: is there a reason that the milestone feature was disabled
on the trac page?
Would it be good/beneficial to put these "must-haves" in a 1.0
milestone, and (some of) the "No" features in a 1.1 milestone?

One of the first things I looked for when I got interested in Django 1.0
was look for the milestone page in trac. I know that there are similar
things in the wiki page, but the status on several of the tickets listed
seem to be stale.

Hopefully my curiosity represents curiosity of others, and I am doing
what I can to push along 1.0, although I'm still getting up to speed on
the development process. :)

Cheers!

Jeff Anderson

signature.asc < 1K Download

Indeed. I expect that anything on that list that doesn't make it into
1.0 will be in 1.1.

Jacob

On Wed, Jun 11, 2008 at 9:23 PM, Jacob Kaplan-Moss

Also, it's worth noting that because contrib.comments is an
application rather than a core part of Django, it will be easy to keep
it available for those who want to stick to it, and if someone in the
community wants to offer continuing support for it I wouldn't be
averse to letting them do so (though of course django.oldforms will
eventually disappear, at which point any third-party maintenance
effort will probably need to do some porting).

--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

This hits the nail right on the head. +1 from me.

On Jun 11, 2008, at 8:03 PM, Jacob Kaplan-Moss wrote:

Just wanted to point out that the newforms-admin branch has already  
ported django.contrib.auth to newforms.

A *really* big fucking party ;)

Brian Rosner
http://oebfare.com

Very reasonable set for 1.0 release. The list of must-haves totally
matches my expectations. +1.

Thanks,

Eugene

On Wed, Jun 11, 2008 at 10:03 PM, Jacob Kaplan-Moss <

...

The django.contrib.auth case has already been done in the newforms-admin
branch, so don't anybody run out and starting working on it for trunk.

One thing I don't see mentioned anywhere is defect #6755 "Model Inheritance
doesn't work in the admin" (whereas GenericForeignKey admin support is
specifically called out).  I don't know if #6755 is classified as must have
for newforms-admin to land (it's not even specifying newforms-admin as the
release anymore), or in the "maybe" category?  It's gotten a fair amount of
interest from people who have started using inheritance so it would be nice
to have its status be specified.

Karen