In case this is way off-base or has been discussed to death in IRC,
I'll keep it short. It's just something I've been thinking about as I
build out my first real Django app and follow the (exciting) progress
toward Django's first "real" release. It didn't seem worthy of a ticket
at this stage.
In
Move it out. It makes Django leaner and more granular. If anybody needs it,
it can be easily installed.
Thanks,
Eugene
"Adrian Holovaty" <[EMAIL PROTECTED]> wrote
in message news:[EMAIL PROTECTED]
Right now, Django checks redirects as a last resort, in the
django.views.defaults.page_not_fo
What is the effect of not having the redirect application installed.
also.. it sounds like we need to be able to install a set of apps at one time.
eg.
admin, comments, redirects.
is it possible to add a command to django-admin to install the common
applications (and configure default URLs etc)
Right now, Django checks redirects as a last resort, in the
django.views.defaults.page_not_found view.
This is not ideal, for a couple of reasons:
* As sopel has brought up, this causes an extra database query for
every 404. Sometimes two queries, depending on whether the URL has a
slash in it.
"Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
>
> 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
+1 for hugo's suggestion. A tarball now gives us a "stable" version to point people to before we start knocking off backwards-incompatible changes. A finalized roadmap for 1.0 puts the target in sight. And 0.9 says "we're almost there". All in favor
On 11/9/05, Jeremy Dunck <[EMAIL PROTECTED]> wrot
On Nov 9, 2005, at 10:48 AM, Adrian Holovaty wrote:
Before we "release it to the masses," so to speak, we should take care
of a small, but important, set of features and fixes. That list is at
http://code.djangoproject.com/wiki/VersionOneFeatures . We'll leave
the list open for discussion until
OK, here's the plan of action --
We'll release a 0.9 version of Django, as a tarball/zip. This will
have no guarantee of backwards compatibility (but will, of course, be
as stable as it's always been).
Before we "release it to the masses," so to speak, we should take care
of a small, but importa
> 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 t
Adrian Holovaty wrote:
> On 11/9/05, hugo <[EMAIL PROTECTED]> wrote:
>
>>I would say: release a 0.9 version now (or in the near future) and give
>>a clear roadmap (that's what the trac feature is for ;-) ) of what will
>>go into 1.0 before release. That way people have some "quite stable
>>but n
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
On 11/9/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 11/9/05, hugo <[EMAIL PROTECTED]> wrote:
> > I would say: release a 0.9 version now (or in the near future) and give
> > a clear roadmap (that's what the trac feature is for ;-) ) of what will
> > go into 1.0 before release. That way pe
On 11/9/05, hugo <[EMAIL PROTECTED]> wrote:
> I would say: release a 0.9 version now (or in the near future) and give
> a clear roadmap (that's what the trac feature is for ;-) ) of what will
> go into 1.0 before release. That way people have some "quite stable
> but not 1.0" tarball to play with
>I have no idea why we have to marry the idea of releasing a tarball to
>the number 1.0, but the number 1.0 is already explicitly married to
>backwards compatibility in the eyes of most users. IMO there are still a
>number of areas that need a fair amount of work.
I would say: release a 0.9 versi
>I also don't like #251 that much, but I'd take it over the >scary
>undocumented "_or" we've got now (and over raw SQL, >which sucks).
How about another solution to expression combination: wrapping query
expressions (the field__exact and friends) optionally in Query()
objects that implement __or_
15 matches
Mail list logo
