On Nov 8, 2005, at 3:41 PM, Robert Wittams wrote:
Ok, so this generated quite a bit of traffic.
Ha -- thanks for kicking this off; it needed to be discussed.
I *really* don't think that 1.0 should be considered on the basis of
stability and usability of the implementation. It should be on the
basis
of "is this a reasonable base to offer backwards compatibility
for", ie
how much do we *know* is going to have to change.
I agree that this is a noble goal, and in a perfect world Django 1.X
would be completely compatible with Django 1.Y. However, the reason
I'm wanted to push out something called "1.0" is that Django's
*perceived* instability is hampering its adoption. The fact is that
people read "0.7" as "zero-point-missing-many-features" and shy
away. With enough eyeballs all bugs are shallow, and I want more
eyeballs (mmmm.... eyeballs....)
These are the things that definitely need to happen before we end up
with a commitment to back compat nightmares:
1) Get rid of core fields * ( this blocks a surprising amount of
stuff).
Agreed (as I've said before).
2) Sort out whether magic model modules are really a good idea. Adrian
was talking about this, I also talked to Simon about this yesterday at
the meetup. I am in favour of getting rid of them.
Let's bring this up on a different thread since it's a big issue; my
10-second response is that this would take a *lot* of time, and
aren't there more important things to be doing?
3) Some kind of story on authorisation that works for people other
than
newspapers, and isn't an enforced ACL mire. *
This is a HUGE task; I think you know that. Coming up with a auth
system that doesn't get in the way of most people but has all the
power you could ask of it certainly is going to be difficult, and
finding consensus among developers on how auth "should" work could
easily turn into a holy war (the last time we discussed the topic the
tone turned nasty fairly quickly). Frankly, I'd guess that for over
90% of Django's users the current simple auth system is *too*
complicated for their needs. This isn't to say that I wouldn't LOVE
to see this happen, but simply that it, too, is a lot of work.
4) Transactions
Agreed.
5) Real subtyping as discussed a few weeks ago *
I could go either way on this; any way you slice it subclassing is
going to be a mismatch to a relational database, but the current
system is needlessly confusing and could be cleaned up.
6) Proper schema checkpointing and transitioning *
This is also a big deal. Again, a lot of what makes this difficult
is coming to a community consensus on what "proper" is. However,
this is certainly something that could be added without sacrificing
backwards compatibility; I'd prefer to take a pass on this and push
it to 1.1.
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.
I was planning to do the * items in a branch before 1.0, with the
explicit aim of doing every breaking change in one lump before 1.0
so as
to minimise the number of times people have to mess with their models.
I really appreciate your intentions, Robert, but going solo on big
features like this is a bad idea from a community standpoint. Many
of the changes you highlight are likely to be controversial and we
*have* to discuss them before they'll make it into Django. For
better or for worse, I don't want this to be the type of open source
project that rolls out big architectural changes without discussing
them with the community.
Reading over what I've written so far, it seems that I'm shying away
from difficult tasks. Perhaps I am, but the fact is that the longer
we linger in a pre-release stage the more our potential community
slips away. I don't use the number "1.0" lightly, and I know that it
locks us in somewhat, but that very lockin is what draws developers
to stable code. Most of the big feature you propose are things that
I would give my left thumb to see added to Django, but at the same
time I don't want Django to become a project that lingers in
perpetual pre-release. 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?
I've added http://code.djangoproject.com/wiki/VersionOneFeatures as a
way of taking a straw poll on what features people feel would be
neccisary to create before we can release a 1.0; I've tried to
summarize the feelings from this thread, so if I mistook anyone's
opinion I apologize in advance.
Thanks,
Jacob
