On Wed, Apr 23, 2008 at 5:58 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > I'll make some time to do a pass through the VersionOneFeatures list and > rationalise things a bit. We can start pulling together a list of > tickets that are absolute blockers, too (I gather James already had some > of that stuff written down somewhere). The trick there is keeping the > list somewhat managed and not suffering form everybody adding pet > features. It's something the release manager should probably own.
I do have a list. I've been wary of publishing it because this sort of thing inevitably turns into a festival of people posting things that are important to *them* but not necessarily important to Django as a whole, and assuming that a refusal to put them on a "1.0 feature list" represents the utter failure of Django as a project. So. Keep three things in mind as you read this: 1. This is not a comprehensive list of every single thing that'll happen before 1.0; this is merely a list of the most important things that need to happen before I'd feel comfortable calling anything "Django 1.0". 2. My criteria for this list involve a combination of things that are huge and universally agreed to be important; things that -- though they may be minor or isolated -- make it noticeably easier to use Django in a common situation; and things that, while less important, involve backwards-incompatible changes and so need to happen before we slap a seal of compatibility on 1.0. 3. Unless you have a commit bit or I'd recognize your name from your contributions to Django, don't take this as an invitation to pitch your pet feature. I'm not trying to be mean here, but there are lots of things that simply aren't requirements -- for the project as a whole -- to get to 1.0, and which can sensibly be dealt with, in incremental fashion, at a later time. As such, I naturally pay a lot more attention to people who've demonstrated their understanding of the big picture. So here goes. First up, the big things: * Queryset-refactor * Newforms-admin * Model-level validation * Anything in Django still using oldforms -> uses newforms These just flat-out have to happen, and represent major work. Fortunately, there are already people doing the work and I believe at least three of the four are getting really close. Then there are things which, while more self-contained, contribute significant improvements in common use cases, and which should happen before 1.0. If you're looking for something to work on and you know Django's codebase, this would be the list you want to look at. * Marty's file backend work needs to land, because that drastically improves both the ease of file handling in general and the ability to use popular storage solutions like Amazon S3. * The refactoring of Django's dispatcher. Jacob and, I believe, Jeremy have been working on this, and it's key because right now signals are incredibly useful but dog-ass slow. * WSGI fixes, particularly for SCRIPT_NAME. Yeah, there's a common pattern people use to work around it, but we should knock this out before 1.0; we already solved the problem of building a full URL for relative redirects, so we should be able to solve this too. * The template tag loading mechanism needs to get fixed; it's the last bit of arguable "magic" in Django, and the number of times now that I've seen people angrily trying to work out why we look in "django.templatetags" indicates that it's causing headaches. * Reverse URL resolution needs some love, because right now there are all kinds of not-too-complex regular expressions that it'll choke on. And since reverse resolution is one of the keys to portable, reusable code, we need to get that cleaned up. * The way django.template.Variable does resolution needs to take filters into account, so that tags which use it can be passed variables with filter expressions and work properly. Then there are some backwards-incompatible things which, while not as big, need to happen. These are going to need an experienced person banging out the design and then coding it up: * The oft-proposed INSTALLED_APPS refactoring needs to happen, so that things like re-using an app multiple times in the same Django instance will be easy and the hackiness of app_label will go away. * The mechanism for specifying and ordering middleware needs to be reworked, so that some of the nastier situations people can get into with figuring out what order to put their middleware in (and some situations where there's simply no possible ordering that works) will go away. And that's my list. Twelve things which, for one reason or another, need to happen before we roll a 1.0 release. Again, that doesn't mean we'll ignore all other work before 1.0, just that these are the really important things that have to happen. And as a pre-emptive note because someone will notice and point it out: yes, there are a couple things that aren't on this list that some folks probably think should be, including: * Refactoring django.contrib.comments * Jacob's documentation refactor * ORM aggregation support Of these three, only one is arguably backwards incompatible, and that's the comment refactor. But it's been proposed as a Summer of Code project, and fortunately it's fairly easy to deal with replacement of a contrib app: we can simply freeze the old one (or, better, find someone interested in maintaining it) and make it available for as long as there's interest. The other two don't cause backwards-incompatible changes, and can basically be rolled out any old time: the docs refactor mostly affects djangoproject.com rather than development with Django, and the aggregation proposal is SoC work that can be added in a post-1.0 point release once it's ready for prime time. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
