> If > we decide that these features can't be done in a backwards-compatible > way and have to release a 2.0 six months after 1.0, what's the harm in > that? >
Thats fine, but that needs to be made absolutely clear. The default that people are going to expect is that we are "satisfied" with the interfaces in Django 1.0, and they will be the focus for development for a while . I have nothing against releasing 1.0, but only *if* it is made clear that it is not a long term maintenance release. I see no actual benefits in releasing something called 1.0 without a back compat guarantee - I really don't share your idea that you can't get a big community without a 1.0 release. Just look -gasp- at Rails. So if the 1.0 release is just a "look at me, I'm usable" release, then I would cut down what I would like done from my last message to core fields, subtyping. The other stuff can wait as long as 1.0 can be semi-abandoned quite quickly. >> 7) Extract the admin history thing from manipulators into a seperate >app* >> >I'm not sure why you feel this is necessary, but it also seems it >could be done with a minimum of backwards-incompatibility (rename >django_admin_log and refactor manipulators slightly). Database >evolution between versions of Django is probably OK as long as the >APIs stay the same. The only reason this is here rather than in new-admin is that it relies on core fields being removed to do it sanely. It wouldn't actually have to be backwards incompatible.
