I think it's time to start a push towards releasing Django 1.0. What follows are my thoughts about how I'd like this process to work.
== What does 1.0 mean for Django? ==
There's a lot of different things that "1.0" can mean. In many cases the label refers to some arbitrary measure of code maturity, but that's usually very indistinct. There's quite a bit of "1.0" software that's far less robust than Django was at day 1; we could have called it "1.0" then and gotten away with it, I think.
In the context of Django, though, 1.0 has always meant something more concrete: forwards compatibility. Once we tag something as 1.0, we're committing to maintaining API stability as described in the contributing HOWTO (http://www.djangoproject.com/documentation/contributing/#official-rel...).
This means that any API in 1.0 *must* continue to work until *at least* 1.2, and we've been concerned about getting those APIs right before we carve them into cement.
So, for the purposes of my proposal, I'm calling 1.0 the point at which all of Django's APIs stabilize. Note that this *doesn't* mean feature-completion -- there's some fascinating work (evolution, per-object-perms, etc.) that when finished will make amazingly valuable additions to Django. None of that influences the release of 1.0 in any way, so I'm going to ignore those kinds of features until the very end.
So -- unstable APIs then. What do we have?
== Unstable APIs ==
* Forms: the newforms library is coming along nicely. There's some work that remains, the bulk of which lies in converting the admin to use newforms instead of manipulators. At that point, the transition can really be called complete.
* Serialization: a few tickets (#2930, #2843, #2650, #2553, and perhaps a few more) need to be reviewed and rolled in or rejected, but other than that I'm willing to call this API stable.
* Authentication: Joseph Kocherhans proposed a couple of changes to the auth code to better allow custom backends. I'm +1 on those changes, and in the absence of any disagreement I'd say the community seems to agree as well. Once that stuff goes in, I think we can pretty easily call the auth framework solid -- any changes in the future could be made in a backwards-compatible way.
* Generic relations: two things need to happen here (a) they need to be moved into the contrib app, and (b) They need to work in the admin. The second probably should wait on the admin rewrite; the first can be done any time.
* Comments: I plan to rewrite this framework to use newforms, and in the process drastically simplify it.
== Other must-haves ==
There's a few other things that aren't "unstable" per-se, but are must-haves for 1.0. I know everyone's gonna have their own list -- and one of the purposes of this thread is to find that list -- but I'd like to keep these minimal. Here's my list of must-haves for 1.0:
* Oracle and SQLServer support. How do people -- especially core comitters -- feel about the Oracle sprint branch? I'd like to merge it; the general outline of the Oracle backend should let the SQLServer folks go to town.
* Test fixtures. I think we're just waiting on Adrian's OK to check this in; I'm +1 on Russ's patch on #2333.
== Handling breakage ==
A few of these things -- the last three, mostly -- will break (some to lots) of code. Just doing it in some arbitrary SVN revision would suck.
So I think we should release a 0.96 in the next week or so, and make the all the backwards-incompatible changes after 0.96. We should announce in as many places as possible that trunk will be moving things around between 0.96 and the next release.
Which brings me to...
== 1.0 roadmap ==
So, here's my roadmap for 1.0:
* Release 0.96 * Finalize all unstable APIs and must-haves referenced above. * Release 1.0rc1 * Resolve (i.e. fix, reject, or defer) all tickets in Trac. * Release rc2 * Call for and fix any large outstanding breakage still in rc2 * Release 1.0
I'm deliberately not mentioning any dates for any of the above, and I won't. I think Adrian might have a timeline in mind and I'm glad to hear it, but I'm not gonna jinx myself :)
== How should this work? ==
So that brings us to a process. Here's how I'd like it to work:
=== Step 1: feature-completion ===
I'd like to appoint a "leader" for each "topic" (unstable API and must-have). This person will have checkin access to their area of interest so they'll need to be someone who's already got checkin or someone who's skilled enough to deserve it. This person can either tackle the issue alone or else form a team to get it done. Here's my list -- any nominations for the missing slots?
* Forms: Adrian * Serialization: Jacob * Authentication: Joseph * Generic relations: ? * Comments: Jacob * Oracle: ? * SQLServer: ? * Fixtures: Russ
Additionally: anyone who volunteers to be the Oracle or SQLServer leader needs to commit to sticking around well after 1.0 to maintain those features. None of the core devs can test those backends, so if they're going to be part of Django they need champions.
=== Step 2: bug fixes ===
Once all the 1.0 features are done, we need to fix bugs.
I think this would be best done through a series of sprints, both physical or virtual. Hopefully we can arrange a few sprints where some of the core devs can physically gather together and check in patches, review tickets, etc etc etc.
I think we can put off planning these sprints in detail until step 1 is complete; I'll just nominate Lawrence and Chicago as my #1 and #2 choices and move on :)
=== Step 3: release ===
We'll need a release manager to make the final decisions about when/what to release, which bugs are vital to be fixed, etc. This is about as far forward as I've thought, though; I'm not sure who this should be, or exactly what responsibilities s/he should have.
On 12 Jan 2007, at 22:39, Jacob Kaplan-Moss wrote:
> There's a few other things that aren't "unstable" per-se, but are > must-haves > for 1.0. I know everyone's gonna have their own list -- and one of > the > purposes of this thread is to find that list -- but I'd like to > keep these > minimal.
On Jan 12, 2007, at 5:39 PM, Jacob Kaplan-Moss wrote:
> == Feedback ==
> Well, have at it :)
How about the docs on the Django site and the Django book site? Newforms, for example, is still fairly under documented, though quickly improving. 1.0 is a big psychological milestone, and will probably draw in a lot of people -- I think it'd be beneficial to make sure all the documentation is in place before the big rush :)
> There's a few other things that aren't "unstable" per-se, but are must-haves > for 1.0. I know everyone's gonna have their own list
As a noob I think you would be making a mistake without a simple Django installer for Windows, one that installs everything needed along with a non-trivial sample application that people can explore.
Since the 1.0 release will cause a lot of people to consider looking seriously at Django and perhaps even Python for the first time, it make sense to lower the barrier to actually doing something useful and seeing how powerful Django really is. I wasn't sold until I had gone through the tutorial.
Getting to the point of being able to start the tutorial is actually more complicated than doing the tutorial. Though I admit it is not too difficult, there are plenty of places where one can screw up with the semi-manual approach currently required.
I'd be happy to take on the installer part if no one else better qualified steps up. I would also be happy to deal with a non-trivial example as soon as I have one. However, I am sure my use of Python/Django idiom will be suboptimal and there is probably something in existence that would be a better example.
One possibility is taking the Tutorial a bit further and having some professional quality templates designed so that it looks impressive. This way prospective users can see what the end result looks like and then the tutorial can take them from scratch to building that example. I can help out here as well if need be.
What sort of timeframe do you envision for 1.0 a few weeks, a few months?
On Fri, 2007-01-12 at 16:39 -0600, Jacob Kaplan-Moss wrote: > Howdy folks --
> I think it's time to start a push towards releasing Django 1.0. What follows > are my thoughts about how I'd like this process to work.
So I've been absent for a couple of months now with work and life commitments, but things are getting back on track (woo-hoo -- once again I will soon have no life.. hmm...wait a minute...). From the beginning of February (around Feb 5), I will be back on deck to do a bunch more Django work, so I feel I should be able to help out a bit here.
[...]
> == Other must-haves ==
> There's a few other things that aren't "unstable" per-se, but are must-haves > for 1.0. I know everyone's gonna have their own list -- and one of the > purposes of this thread is to find that list -- but I'd like to keep these > minimal. Here's my list of must-haves for 1.0:
> * Oracle and SQLServer support. How do people -- especially core comitters -- > feel about the Oracle sprint branch? I'd like to merge it; the general outline > of the Oracle backend should let the SQLServer folks go to town.
> * Test fixtures. I think we're just waiting on Adrian's OK to check this in; > I'm +1 on Russ's patch on #2333.
* Model inheritance: This is top of my list to fix/finish. The backwards-incompatible bit here (in a sense) is getting MI working at all. The "under the covers" transparent portion that I was trying to do first was refactoring the way we construct queries in order to construct more efficient SQL (e.g. not using left outer joins when we don't need them) and to be a bit more easily extensible for things like Oracle, SQL Server and people who want to override query sets to add "group by" and "having clauses". I'm going to reverse the order here: get MI working (visible change), then go back to QuerySet stuff (which is functionally invisible if you don't want to use the extra stuff). Part two here is less important now, since the Oracle and SQL Server backends have made do in other creative ways, although extensions to allow aggregations for those who want them might make things helpful.
* Autoescaping: I think this needs to stay on the radar at least. We came dangerously close to a consensus on this (both in discussions on this list, based on Simon's proposal) and the discussions you, I and Adrian had at OSCON. There is a patch in Trac that implements the whole thing ( + tests + documentation), although it won't apply at the moment because of the text fixture changes. I'll update the patch in early Feb, but I think it might be worth having this in 1.0 -- particularly if we want to have "on by default", since that is a real backwards-incompat change -- but just as a marketing item, since it really is a bit of a liability at the moment.
[Since it will no doubt come up, I'll just mention that I'm not as enthused about SmileyChris's alternative AutoEscaping idea -- in the wiki -- because some of the points it addresses aren't really problems, I feel, and is very difficult to integrate with custom tags (or even things like linebreaksbr, etc). I may be biased, though, since I liked Simon's original proposal.]
[...]
> == 1.0 roadmap ==
> So, here's my roadmap for 1.0:
> * Release 0.96 > * Finalize all unstable APIs and must-haves referenced above. > * Release 1.0rc1 > * Resolve (i.e. fix, reject, or defer) all tickets in Trac. > * Release rc2 > * Call for and fix any large outstanding breakage still in rc2 > * Release 1.0
> I'm deliberately not mentioning any dates for any of the above, and I won't. > I think Adrian might have a timeline in mind and I'm glad to hear it, but I'm > not gonna jinx myself :)
This plan is ambitious enough that dates will be fun to watch as they go whizzing by. But having some kind of step-by-step and some momentum to actually get to 1.0 is going to help us.
> So that brings us to a process. Here's how I'd like it to work:
> === Step 1: feature-completion ===
> I'd like to appoint a "leader" for each "topic" (unstable API and must-have). > This person will have checkin access to their area of interest so they'll > need to be someone who's already got checkin or someone who's skilled enough > to deserve it. This person can either tackle the issue alone or else form a > team to get it done. Here's my list -- any nominations for the missing slots?
> * Forms: Adrian > * Serialization: Jacob > * Authentication: Joseph > * Generic relations: ? > * Comments: Jacob > * Oracle: ? > * SQLServer: ? > * Fixtures: Russ
I'm happy to take on Generic relations (at least the moving portion and to work out the pieces needed for when we get the admin rewrite done). I'm also happy to do model inheritance. And seriously, if you have other items that need volunteers, just put my name in. I can make time in the next couple of months.
I guess I'd also like to see "documentation coverage" as an item there: each individual component has its documentation as part of the work done on it, but we need to check we really are covering all bases and fill in the places that we've said "will be done eventually". I'm happy to take on that job -- it's just (virtual) paperwork, mostly, keeping lists of what we are missing and what tickets exist in that arena (and then checking off as Adrian adds contractions and proofreads things).
> Additionally: anyone who volunteers to be the Oracle or SQLServer leader needs > to commit to sticking around well after 1.0 to maintain those features. None > of the core devs can test those backends, so if they're going to be part of > Django they need champions.
> === Step 2: bug fixes ===
> Once all the 1.0 features are done, we need to fix bugs.
> I think this would be best done through a series of sprints, both physical or > virtual. Hopefully we can arrange a few sprints where some of the core devs > can physically gather together and check in patches, review tickets, etc etc etc.
> I think we can put off planning these sprints in detail until step 1 is > complete; I'll just nominate Lawrence and Chicago as my #1 and #2 choices and > move on :)
If you can give as much notice as possible for these, I'd like to fly over and be onsite. Virtual sprinting from another timezone is not always easy, although I'll give it a go if that's all there is.
> === Step 3: release ===
> We'll need a release manager to make the final decisions about when/what to > release, which bugs are vital to be fixed, etc. This is about as far forward > as I've thought, though; I'm not sure who this should be, or exactly what > responsibilities s/he should have.
Agreed. You are probably talking about two jobs there, though: a final call on things (you or Adrian, I suspect) and somebody (the Key Master... er Bugmaster) to track to the "release critical" bugs and keep things organised both for hammering the worker bees and feeding the decisions up to the Final Decision Maker (tm).
On Jan 12, 2007, at 3:28 PM, John Sutherland wrote:
> On 12 Jan 2007, at 22:39, Jacob Kaplan-Moss wrote: >> There's a few other things that aren't "unstable" per-se, but are >> must-haves >> for 1.0. I know everyone's gonna have their own list -- and one of >> the >> purposes of this thread is to find that list -- but I'd like to >> keep these >> minimal.
> What's the story with model inheritance?
Wasn't this dependent on query refactoring that Malcolm was working on?
> How about the docs on the Django site and the Django book site?
First, please consider the book somewhat separate from Django itself. Though Adrian and I are the authors, and though we're involving the community as much as possible, the release schedule for the book is independent from any plans for Django. That is, we need to take the publisher's needs into account for the book, but those needs shouldn't -- and won't -- influence whatever we decide for Django itself.
That said...
> Newforms, for example, is still fairly under documented, though > quickly improving.
1/22 should see the publication of the book chapter on newforms :)
> 1.0 is a big psychological milestone, and will > probably draw in a lot of people -- I think it'd be beneficial to > make sure all the documentation is in place before the big rush :)
Yes, this is a very good point. I've been considering "documentation" as part of the "bug fixing" (i.e. stage 2); perhaps it's its own task and should be added as part of the "finalization" (step 1) stuff.
Yeah, as I think about it, I think docs are important enough they need their own "leader" as well. That person could additionally take control of the documentation index -- which is getting a bit difficult to use -- and the FAQ.
> As a noob I think you would be making a mistake without a simple Django > installer for Windows, one that installs everything needed along with a > non-trivial sample application that people can explore.
Good point. Eugene sent me a windows installer a while ago, but I didn't have a chance to test it out and then I lost track of it....
Let's table this until closer to the release, but if you want to talk to him and anyone else and start lining things up for a windows installer, we'd love to have one.
> So I've been absent for a couple of months now with work and life > commitments, but things are getting back on track (woo-hoo -- once again > I will soon have no life.. hmm...wait a minute...). From the beginning > of February (around Feb 5), I will be back on deck to do a bunch more > Django work, so I feel I should be able to help out a bit here.
Yay!
You of course shouldn't feel any obligations, but it'll be quite nice to have your help :)
> * Model inheritance
[snip]
I actually had this on my original list, but then I took it off -- it seems to me that allowing MI wouldn't break any existing code (just allow new code to, you know, work correctly). If that's true, I'd be OK introducing it post-1.0
However, if I'm wrong then this does need to be on the roadmap for 1.0.
> * Autoescaping: I think this needs to stay on the radar at least. We > came dangerously close to a consensus on this (both in discussions on > this list, based on Simon's proposal) and the discussions you, I and > Adrian had at OSCON.
Ah, yes :)
I think I'm really the only one who's still holding out for manual escaping, so in the interests of Getting Things Done I'm gonna shut up about it. Is there anyone besides me who *doesn't* want auto escaping (in some form) in Django? If so, let's hear it now.
> There is a patch in Trac that implements the whole > thing ( + tests + documentation), although it won't apply at the moment > because of the text fixture changes. I'll update the patch in early Feb,
Cool - I look forward to playing with you
> This plan is ambitious enough that dates will be fun to watch as they go > whizzing by. But having some kind of step-by-step and some momentum to > actually get to 1.0 is going to help us.
Let's keep things abstract for a couple of days at least, but once we've got the hit list for 1.0 ironed down, you're right that someone should set a timeline.
It's just not gonna be me :)
> I'm happy to take on Generic relations (at least the moving portion and > to work out the pieces needed for when we get the admin rewrite done).
That's fantastic. I've got some code for the admin kicking around that should be OK to adapt and finish off for newforms. I'll put you on my list as the mover and I'll be the shaker (er, the admin guy).
> I guess I'd also like to see "documentation coverage" as an item there:
See my previous post about this -- I agree 100%.
> If you can give as much notice as possible for these, I'd like to fly > over and be onsite. Virtual sprinting from another timezone is not > always easy, although I'll give it a go if that's all there is.
Yeah, will do.
> Agreed. You are probably talking about two jobs there, though: a final > call on things (you or Adrian, I suspect) and somebody (the Key > Master... er Bugmaster) to track to the "release critical" bugs and keep > things organised both for hammering the worker bees and feeding the > decisions up to the Final Decision Maker (tm).
Ahhh - that's the part I hadn't quite figured out myself. Good call.
> * Forms: the newforms library is coming along nicely. There's some work that > remains, the bulk of which lies in converting the admin to use newforms > instead of manipulators. At that point, the transition can really be called > complete.
Adrian said that he wanted to make inline collections easier. I thought that this is a real big thing, and will completely redefine how the admin implements inline editing. And probably deeper. (Just had a look at AutomaticManipulator.save ... gosh)
Not to forget: newforms will have a big influence on generic views, too.
Michael
-- noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - Tel +49-911-9352-0 - Fax +49-911-9352-100
> Adrian said that he wanted to make inline collections easier. I > thought that this is a real big thing, and will completely redefine > how the admin implements inline editing. And probably deeper. (Just > had a look at AutomaticManipulator.save ... gosh)
Heh.
Yeah, this is part of reworking the admin to use newforms. I think Adrian's got a plan here, so I'll let him answer more completely if he wants :)
> Not to forget: newforms will have a big influence on generic views, > too.
Good point; someone's going to need to rework those, as well.
Jacob Kaplan-Moss wrote: > I'd like to appoint a "leader" for each "topic" (unstable API and must-have). > This person will have checkin access to their area of interest so they'll > need to be someone who's already got checkin or someone who's skilled enough > to deserve it. This person can either tackle the issue alone or else form a > team to get it done. Here's my list -- any nominations for the missing slots?
What about things that don't match any of those things? Should misc. patches be discussed before or after .96?
> On 1/12/07 6:40 PM, Michael Radziej wrote: >> Adrian said that he wanted to make inline collections easier. I >> thought that this is a real big thing, and will completely redefine >> how the admin implements inline editing. And probably deeper. (Just >> had a look at AutomaticManipulator.save ... gosh)
> Heh.
> Yeah, this is part of reworking the admin to use newforms. I think Adrian's > got a plan here, so I'll let him answer more completely if he wants :)
If he did, this thread would be overtaken by discussions about newforms, widgets, and html vs. xhtml ;-)
Michael
-- noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - Tel +49-911-9352-0 - Fax +49-911-9352-100
> What about things that don't match any of those things? Should misc. > patches be discussed before or after .96?
Well, you'll need to be a bit more specific about what "things" you're talking about. I think, though, that there are three possibilities for any "thing":
* If Feature X absolutely can't be implamened post-1.0 without breaking 1.0 APIs, then it needs to be accepted or rejected now. This case covers BIG features like, well, rewriting Django's form handling. I don't think that there are many of these.
* If Feature X could be done post-1.0, a decision about it would be made during the ticket triage process (step 2 in my outline). That decision will be either "reject", "accept", or "defer" (to 1.1 or whatever).
Jacob Kaplan-Moss wrote: > On 1/12/07 6:02 PM, Malcolm Tredinnick wrote:
>> * Autoescaping: I think this needs to stay on the radar at least. We >> came dangerously close to a consensus on this (both in discussions on >> this list, based on Simon's proposal) and the discussions you, I and >> Adrian had at OSCON.
> Ah, yes :)
> I think I'm really the only one who's still holding out for manual escaping, > so in the interests of Getting Things Done I'm gonna shut up about it. Is > there anyone besides me who *doesn't* want auto escaping (in some form) in > Django? If so, let's hear it now.
I would prefer that auto-escaping didn't make it into Django. It may be an overly utopian ideal, but I think security issues, including escaping, should be a conscious effort involving research and understanding of the situation. Without that, it's like blindly adding bandaids to your application hoping they'll keep the holes closed.
Besides, auto-escaping reminds me of PHP's "magic quotes" and we all know how well that turned out... :)
On 1/12/07, Chris Nelson <ch...@karma.net.nz> wrote:
> I would prefer that auto-escaping didn't make it into Django. It may be > an overly utopian ideal, but I think > security issues, including escaping, should be a conscious effort > involving research and understanding of the > situation. Without that, it's like blindly adding bandaids to your > application hoping they'll keep the holes closed.
> Besides, auto-escaping reminds me of PHP's "magic quotes" and we all > know how well that turned out... :)
This comment set off all of my here-comes-a-200-message-mailing-list-saga alarms, so before anybody responds to this, *please* start the response in another mailing-list thread.
Adrian
-- Adrian Holovaty holovaty.com | djangoproject.com
On 1/12/07, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> Yeah, as I think about it, I think docs are important enough they need their > own "leader" as well. That person could additionally take control of the > documentation index -- which is getting a bit difficult to use -- and the FAQ.
I've volunteered in the past and will happily volunteer again to take up maintenance and organization of the docs.
-- "May the forces of evil become confused on the way to your house." -- George Carlin
What about one-to-one relationships? They seem to have had a deprecated status for some time now.
In addition to organizing the documentation, I'd also like to see some cleaning up and reorganization in the wiki. It also should be at least somewhat collaborative work, maybe some sprint weekend or similar. I think that the wiki is a great and valuable addition to the official docs, but it's getting very hard to navigate and find stuff as the content keeps growing.
The main thing i'm missing is a workable reversed url resolver. Or at least an easy way to define/extend the current implementation. There was already some discussion about it (see Proposal: Root view). As it seems such a thing, while being said to be backwards compatible, change the current way url resolving works it would be nice have it in 1.0. (And it seems that Django is the only modern platform not have more advanced reverse url lookup)
Jacob Kaplan-Moss wrote: > * Forms: the newforms library is coming along nicely. There's some work that > remains, the bulk of which lies in converting the admin to use newforms > instead of manipulators. At that point, the transition can really be called > complete.
it seems that noone mentioned unicode in this discussion yet...
does this mean, that the plan is to have django-1.0 still use bytestrings?
because if yes, then i would recommend to "downgrade" newforms to bytestrings too.
the reason is consistency...
if i'm not mistaken, newforms works internally in unicode, and also outputs unicode... which is quite nice, but the problem is, the rest of django is in bytestrings...
so, at the end, in a django-view:
- GET/POST is in bytestrings - newforms outputs unicode - the templates output bytestrings - the db-api outputs bytestrings
it is true, that with various hacks the newforms can be used from the bytestring-based templates, and also they can save models to the bytestring-based db-api. but it is not nice.
the other way is to switch django to unicode completely.
from the past discussion it seems, that many people wanted to work on it , patches were created, so i think the unicode-conversion could happen in a reasonable time.
please don't forget that every feature that you propose and that gets into the 1.0 list will delay 1.0. Everybody has their favorite pet, and with any project and any milestone, its the same: everybody tries to push their favorites in.
The most important goal of 1.0 are stable APIs, i.e. that in future releases the APIs need to be compatible. So, I suggest to add features only if they will break existing APIs, or if they don't hold up things (and that means, somebody can provide high quality patches that can be integrated easily). It will always be possible to add features that introduce new APIs later.
Here's a summary of what I found about the proposed changes:
Changes feature APIs? Implementation? Decision? ------------------------------------------------------------------- newforms Yes No, but on the way Yes serialization No No No authentication Yes Yes Yes generic relation Yes No Yes comments No No, but jacob takes Yes oracle No Almost Yes test fixtures No Yes Yes root views/url rev. Yes No No autoescape No Almost Almost
Remarks:
'Changes API' referes to making an incompatible change to the API.
'Decision': I've taken Jacob's or Adrian's statements as a decision whether about how this feature should be done and whether it is ripe for 1.0. There's a good chance left that I misunderstood (sorry).
Specifics:
Serialization: #2930 has not been decided and does not include a patch. #2843 is not changes the API only in a compatible way and there is no decision in the ticket. #2650 is a bug and not an enhancement, and it does not include a patch but complete files (but bug fixes should go in 1.0 anyway, if possible). #2553 proposes to make generic views respond in formats other than html, and it does not go into details nor does it include a patch. From the description I couldn't find out what it actually proposes, but it looks like a compatible change.
Comments: Jacob plans to rewrite them for newforms. I'd say this change actually belongs into the category 'newforms'. I'm not entirely convinced that it is necessary to rewrite the comments in 1.0, though. Other than the changes in admin, the comments system rewrite shouldn't directly influence the API of newforms.
Oracle: While it doesn't change APIs, having an oracle backend is great for the 1.0 release, even if it doesn't contribute to the #1 goal. And there is great impetus behind it.
The root view proposal was blocked by the problem of url reversal. A few possible solutions have been brought up that had some disadvantages, and nobody of the core team has commented on this.
Autoescape only changed APIs if it was on by default. But I've followed the discussion very closely, and I'm sure that the main reaction of the community was strictly against this. autoescape is my own favorite pet, but when I apply my own criteria, it wouldn't be a candidate for 1.0. One could argue that it will deeply affect the way templates are written and that they are an important step to make django applications safe, but the consensus about it was not that strong. Or do we want to use it in the admin?
I'm creating a wiki page for this summary (with some more information). Can somebody fill me in about the tickets for authentication?
Jacob Kaplan-Moss wrote: > Good point. Eugene sent me a windows installer a while ago, but I didn't have > a chance to test it out and then I lost track of it....
> Let's table this until closer to the release, but if you want to talk to him > and anyone else and start lining things up for a windows installer, we'd love > to have one.
I'm pretty comfortable with the Nullsoft Installer (NSIS: nsis.sf.net). If Django decides to use that, I'd be happy to help.
Should we start a separate thread to answer questions like:
* Should we use default Python or something like Portable Python? * Assume SQLite? * Install any add-ons (like Markdown or Textile)?
I have left the old contents that have seen the last edit in July in place under a section 'obsolete' to move them around as the plans become more clearer.
In addition to my preceding posting, I've added the items model inheritance, ms sql server and windows installer, which I've somehow overlooked.
> I'm sure sure ticket-wise, but Joseph posted his plans to the list a > couple of days ago.
