Very reasonable set for 1.0 release. The list of must-haves totally matches my expectations. +1.
Thanks, Eugene Jacob Kaplan-Moss wrote: > 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 > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
