Re: Django 1.0 features -- the definitive list

[James Bennett]

On 11/30/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Let's get a definitive list of features we want in Django 1.0, and
> let's release it.

Sounds great to me :)

> What am I forgetting?

I'd add model subclassing to the list, if only because it feels as if
the API has been mostly agreed upon at this point, and a whole lot of
documentation updates/additions and possibly refactoring (there's
plenty of room for post-1.0 improvement, of course, but there are also
a lot of things we should document if we're going to commit to
maintaining compatibility).

> My second reason for choosing 2.0 is, shall we say, less wholesome.
> After having endured a 2.5+ year deluge of "When is 1.0 coming out?"
> blog entries, comments, e-mails and in-person confrontations from
> people all around the world, I would find it incredibly satisfying, in
> a devilish way, to release this thing and slap a "2.0" on it. It would
> underscore the project's stability while at the same time
> demonstrating that version numbers are completely arbitrary.

I'd be OK with it; in my previous life as a PHP guy I worked a lot
with Textpattern, which went through a multi-year development process
and then decided to call the result "version 4.0" ;)


-- 
"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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Ivan Sagalaev]

Adrian Holovaty wrote:
> Without further ado, here's my list:
> 
> * newforms-admin
> * queryset-refactor
> * django.newforms becomes django.forms
> * Model-level validation
> * Change django.templatetags not to use __path__ hacking
> * #3591 -- Make INSTALLED_APPS an instance, and each app an instance
> * #5361 -- File storage refactoring
> * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
> 
> What am I forgetting?

Adrian, people will rip you apart for omitting streamed file upload :-). 
   Though I believe it will require a lot of effort since the main 
ticket on the subject (#2070) looks scary.

> I think we ought to call the release 2.0.

I would be -0 emotionally. I'm afraid nobody will understand the reason 
just from the number and we'll have a whole lot of confusion ("where's 
1.0 then?", "so those version numbers don't mean anything?", "what were 
they smoking?")

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Max Battcher]

On Nov 30, 2007 2:18 AM, jj <[EMAIL PROTECTED]> wrote:
> move 0.96 to 1.0 status. This might sound somewhat artificial, but
> would clearly indicate that 0.96 is a version one can already trust.
> Isn't the Web site already advocating 0.96 that way?

That might be a good idea...  backport any remaining useful fixes to
0.96, maybe go ahead and do the newforms -> forms rename, and not much
more really needs to be done and call that 1.0 and everything else
becomes 2.0...

On the other hand I also see the humor in skipping directly from 0.96 to 2.0.

The way changes steadily get pushed to Trunk I'm wondering if Django
might not be better off using Ubuntu-style date-based versions,
anyway.  (ie, the current Ubuntu release was official in October 2007
and thus is version 7.10)   I think it would be even funnier to skip
from 0.96 to 8.01... and then follow that up with new versions each
quarter, if not each month...

-- 
--Max Battcher--
http://www.worldmaker.net/

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Karen Tracey]

On 11/30/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> [snip]
>
> We're currently leaning more towards Joseph Kocherhans' replacement for
> form_for_* (not sure how backwards compatible it will end up) and whilst
> "nice to have", I don't see this as show stopper stuff for 1.0.
>
>
Except I've gotten the impression that these form_for_* changes would be
very helpful in getting some of the newforms-admin loose ends tied up
(edit-inline in particular, I believe).  Thus since the basic idea has
gotten a positive response and there is already an initial implementation, I
wouldn't be surprised to see the form_for_* changes become a pre-req to
getting newforms-admin finished, which would turn them into a show-stopper
for 1.0.  This is just my impression, though, Joseph might very well have a
different view.

On the issue of what to call 1.0, I like Max Battcher's idea of adopting an
Ubuntu-like date-based version.  Puts some useful information (how old is
it?) into the release name and avoids preconceived notions of
stability/completeness associated with .0 releases.

Karen

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Gary Wilson]

Adrian Holovaty wrote:
> Without further ado, here's my list:
> 
> * newforms-admin
> * queryset-refactor
> * django.newforms becomes django.forms
> * Model-level validation
> * Change django.templatetags not to use __path__ hacking
> * #3591 -- Make INSTALLED_APPS an instance, and each app an instance
> * #5361 -- File storage refactoring
> * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
> 
> What am I forgetting?

newforms in generic views and comments too.  This isn't being taken care of in
newforms admin is it?

We also have the features page made before the last sprint:
http://code.djangoproject.com/wiki/VersionOneFeatures

On a related note, the maxlength argument is currently issuing a
PendingDeprecationWarning.  It was talked that we would change to
DeprecationWarning before the next release, but I think it should die before
.0.

Should we change to DeprecationWarning now and remove it before the release or
just axe it all now?

> And, finally, a bit of a controversial statement, but...
> 
> I think we ought to call the release 2.0.

"The birth of Django"
1.910

Gary

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Simon Willison]

On Nov 30, 6:33 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> What am I forgetting?

It's probably too big a feature to start talking about now, but I'd be
really interested in seeing Django applications (in particular the
URLconf part) unified with the concept of a Django view, so a Django
application is a callable that takes a request object and returns a
response - and in fact an entire Django deployment can be boiled down
to that. This has a number of advantages:

1. At the moment, middleware applies globally to the whole site. This
is bad: often you'll want a piece of middleware to apply just to one
or two of the applications that a site is composed of. If views and
applications (and projects) had a unified API then middleware could be
redefined to apply at any level of the stack. View middleware wouldn't
make so much sense here, but Request and Response middleware would.
2. We always said that the regular expression based URL dispatching
should be replaceable by other methods if required. Having url
dispatch as just another view function would give us that for free.
I'd love to have a simpler alternative to the regexp method that is
more friendly for developers who haven't fully grokked regular
expression syntax yet.

If there's enough interest in the DEP idea I'd be happy to write up
this proposal more formally.

Cheers,

Simon
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Mark Green]

On Fri, 2007-11-30 at 00:33 -0600, Adrian Holovaty wrote:
> (I've been saving this e-mail since the last sprint. Given that we're
> sprinting again this weekend, I figured it was about time to get this
> conversation started.)
> 
> Let's get a definitive list of features we want in Django 1.0, and
> let's release it.

Great. Just great! :-)
A small suggestion (and it's probably obvious): It would be awesome
if, once the features are determined, someone could take the time and
make a trac milestone out of the tickets that belong to this goal.

The "roadmap"-feature of trac would then give us a nice progress-bar
and could help to draw more focus onto the relevant tickets.


-mark



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Simon Willison]

On Nov 30, 6:33 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> I think we ought to call the release 2.0.

I'm -0.5 on this (if that's possible). I understand the thinking
behind it, but "1.0" isn't an arbitrary version number - it has a very
specific meaning: "the APIs are frozen, it's safe to build things
without worrying that backwards compatibility will be broken". That's
what we've been telling people for the past couple of years, and as a
result I feel it would be odd to use 2.0 to make the statement that
version numbers are meaningless after all.

I think that the release of v1.0 combined with the publication of the
Django Book will result in a serious uptick in interest in the project
(and that's not saying that there isn't plenty of interest already). I
wouldn't want to see some of that interest diverted by confusion over
version numbers.

Cheers,

Simon
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[David Cramer]

Is this set for 2009? ;)

About subclassing, what was agreed upon? I'm going to rip my hair out
if it does OneToOne relations and strange db queries :P

I think the major features listed here are good -- qsrf is the biggest
one I want in.. come on .98? :)

On Nov 30, 9:49 am, "Bryan L. Fordham" <[EMAIL PROTECTED]>
wrote:
> > On the issue of what to call 1.0, I like Max Battcher's idea of
> > adopting an Ubuntu-like date-based version.  Puts some useful
> > information (how old is it?) into the release name and avoids
> > preconceived notions of stability/completeness associated with .0
> > releases.
>
> I'm +1 on that as well. Seriously, how many of us have been running
> these pre-1.0 versions in production with no real problems?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Adrian Holovaty]

On Nov 30, 2007 11:56 AM, Derek Anderson <[EMAIL PROTECTED]> wrote:
> what, no schema evolution?  =p

Schema evolution falls squarely in the category of "inessential for
this version, but can always be added in a subsequent incremental
version without breaking backwards compatibility."

Adrian

-- 
Adrian Holovaty
holovaty.com | djangoproject.com

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Derek Anderson]

what, no schema evolution?  =p

(ducks for cover behind fire-retardant suit ;)


Adrian Holovaty wrote:
> (I've been saving this e-mail since the last sprint. Given that we're
> sprinting again this weekend, I figured it was about time to get this
> conversation started.)
> 
> Let's get a definitive list of features we want in Django 1.0, and
> let's release it.
> 
> I'll start with a proposed list, which no doubt has omissions. But
> first, here's a proposal for how to handle this:
> 
> 1. We decide on the list of features/changes.
> 
> 1.5. Once the list is final, we do NOT add to it except in case of
> an Act of God.
> 
> 2. We set a deadline.
> 
> 3. We work -- *primarily* on the list of features/changes, but
> allowing some time for squeezing in any other small fixes that we have
> time for.
> 
> 4. Any feature that's not implemented by the deadline does NOT
> make it into version 1.0. But fear not, because version 1.0 is not the
> end of Django -- it's only the beginning!
> 
> 5. Release, rejoice.
> 
> The first order of business is deciding the features/changes. I'll
> kick it off with the list I've been keeping.
> 
> This is just my own list, of course, and I'm sure other
> committers/contributors have other stuff. Please contribute! Just one
> important thing to note: This list is for Big Stuff only. Do not
> suggest features that would be able to be added/changed *after* the
> 1.0 release in a backwards-compatible way. The goal here is to have a
> simple, concrete list of major things that need to be done to the
> framework -- not a list of 4,000 tiny things.
> 
> Without further ado, here's my list:
> 
> * newforms-admin
> * queryset-refactor
> * django.newforms becomes django.forms
> * Model-level validation
> * Change django.templatetags not to use __path__ hacking
> * #3591 -- Make INSTALLED_APPS an instance, and each app an instance
> * #5361 -- File storage refactoring
> * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
> 
> What am I forgetting?
> 
> And, finally, a bit of a controversial statement, but...
> 
> I think we ought to call the release 2.0.
> 
> Jacob and I have talked in the past about how we should've called
> magic-removal version 1.0. (This ended up being 0.95.) For all intents
> and purposes, it *was* 1.0 in spirit -- it was the first major
> refactoring of several parts of the framework, and it was a point for
> me personally where I started to feel like an acceptable number of the
> legacy warts from pre-open-sourcing had been removed.
> 
> So, that's one reason: philosophically, conceptually, in our minds, in
> our hearts, we're really dealing with a 2.0 product. We know Django
> rocks (and is rock-solid), and we should give it an appropriate
> number.
> 
> My second reason for choosing 2.0 is, shall we say, less wholesome.
> After having endured a 2.5+ year deluge of "When is 1.0 coming out?"
> blog entries, comments, e-mails and in-person confrontations from
> people all around the world, I would find it incredibly satisfying, in
> a devilish way, to release this thing and slap a "2.0" on it. It would
> underscore the project's stability while at the same time
> demonstrating that version numbers are completely arbitrary.
> 
> It'd be like Google's IPO price, which was set to the mathematical
> constant "e" -- a "we're not playing by your rules" message to Wall
> Street.
> 
> Something to ponder!
> 
> Adrian
> 


-- 
  looking to buy or sell anything?

 try: http://allurstuff.com

  it's a classified ads service that
  shows on a map where the seller is
  (think craigslist + google maps)

  plus it's 100% free :)


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Patryk Zawadzki]

2007/11/30, Malcolm Tredinnick <[EMAIL PROTECTED]>:
> On Fri, 2007-11-30 at 16:46 +0100, Patryk Zawadzki wrote:
> > For my needs:
> >
> > * Extendable results of form_for_{instance,model} (sometimes you just
> > need to override one field in a large form)
> > * Sortable fields on forms extending other forms
>
> This is the sort of thing where it wouldn't be a complete loss if it
> didn't make it into 1.0, since form construction helpers are just that:
> helpers. They don't depend on core changes and don't require core
> changes to support them. Hence, somebody can just write something
> outside of core that meets their purposes.
>
> We're currently leaning more towards Joseph Kocherhans' replacement for
> form_for_* (not sure how backwards compatible it will end up) and whilst
> "nice to have", I don't see this as show stopper stuff for 1.0.

You seem to overlook the part about defining field order for forms
extending other forms. That's in no way related to form construction
helpers (other than being useful for them as well).

-- 
Patryk Zawadzki
PLD Linux Distribution

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Derek Anderson]

twas a joke.  i don't think any of the authors of any of the evolution 
mechanisms believe their implementations ready to be included into v1.0. 
  (my own included :)


Adrian Holovaty wrote:
> On Nov 30, 2007 11:56 AM, Derek Anderson <[EMAIL PROTECTED]> wrote:
>> what, no schema evolution?  =p
> 
> Schema evolution falls squarely in the category of "inessential for
> this version, but can always be added in a subsequent incremental
> version without breaking backwards compatibility."
> 
> Adrian
> 


-- 
  looking to buy or sell anything?

 try: http://allurstuff.com

  it's a classified ads service that
  shows on a map where the seller is
  (think craigslist + google maps)

  plus it's 100% free :)


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Barry Pederson]

Ivan Sagalaev wrote:
> 
> Adrian, people will rip you apart for omitting streamed file upload :-). 
>Though I believe it will require a lot of effort since the main 
> ticket on the subject (#2070) looks scary.

Ohh yeah, that's one feature I'd love to see go in.  An awful lot of 
work has gone into that over the last 15 months - it'd be a shame to see 
it not make the cut.

Barry

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Luke Plant]

On Friday 30 November 2007 06:33:31 Adrian Holovaty wrote:

> Without further ado, here's my list:
>
> * newforms-admin
> * queryset-refactor
> * django.newforms becomes django.forms
> * Model-level validation
> * Change django.templatetags not to use __path__ hacking
> * #3591 -- Make INSTALLED_APPS an instance, and each app an instance
> * #5361 -- File storage refactoring
> * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
>
> What am I forgetting?

Middleware ordering really needs looking at:
  http://code.djangoproject.com/ticket/730
  http://code.djangoproject.com/ticket/749

A small backwards incompatible fix here, I think should be looked at:
  http://code.djangoproject.com/ticket/4619

Luke


-- 
"Mediocrity: It takes a lot less time, and most people don't realise 
until it's too late." (despair.com)

Luke Plant || http://lukeplant.me.uk/

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Forest Bond]

Hi,

On Fri, Nov 30, 2007 at 08:12:14AM -0600, Malcolm Tredinnick wrote:
> On Fri, 2007-11-30 at 08:33 -0500, Forest Bond wrote:
> > On Fri, Nov 30, 2007 at 12:33:31AM -0600, Adrian Holovaty wrote:
> > > * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
> > 
> > Aren't there SCRIPT_NAME/PATH_INFO/etc. problems with mod_python, too?  
> > It'd be
> > nice if django 1.0-based apps could be moved to different relative mount 
> > points
> > without changing .py files at all.  Or was this resolved when I wasn't 
> > looking?
> 
> It's all the same issue. This is one of the things I'm going to review
> and commit during the sprint.

I was hoping you'd say that.  Thanks!

-Forest
-- 
Forest Bond
http://www.alittletooquiet.net


signature.asc
Description: Digital signature

Re: Django 1.0 features -- the definitive list

[Kenneth Gonsalves]

On 30-Nov-07, at 6:14 PM, Deryck Hodge wrote:

> +1
>
> It's not an unprecedented idea across OSS projects.   We jumped from
> samba 3.0.14 to 3.0.20 when we had a slew of new changes between
> releases.  Granted those are dot releases, but the idea is the same.

and postgres jumped from 7.4.x to 8.0

-- 

regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/web/
Foss Conference for the common man: http://registration.fossconf.in/web/



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Patryk Zawadzki]

2007/11/30, Forest Bond <[EMAIL PROTECTED]>:
> On Fri, Nov 30, 2007 at 12:33:31AM -0600, Adrian Holovaty wrote:
> > * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
>
> Aren't there SCRIPT_NAME/PATH_INFO/etc. problems with mod_python, too?  It'd 
> be
> nice if django 1.0-based apps could be moved to different relative mount 
> points
> without changing .py files at all.  Or was this resolved when I wasn't 
> looking?

Start using lighttpd + fcgi instead of Apache ;)

--
Patryk Zawadzki
PLD Linux Distribution

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Alex Myodov]

Sorry for the shameless messing in, but... if you want a release to be
considered rock-stable and proven from the beginning,.. never name it
2.0. Neither 1.0. Nor any *.0.
"Anything-dot-zero" obviously stands for "just released after a rush
to fit into the deadline" and implies "let's wait for other test
mouses to try it and spot the major bugs, and deploy it after a couple
of bugfix releases".
(And by the way, "Django 2.0" definitely implies you have a lot of
Ajax and shiny buttons in it,... and something like Dojo is heavily
integrated).

If you want everyone consider it stable - name it "Django 1.5" or
something. "No service packs needed".

And if you want an incredible showoff and the mention in every IT-
related news magazine - name it "Django 1.6" and announce that every
new version is the next approximation to the Golden Ratio ( the second
release will be Django 1.62, the third will be Django 1.618 and so
on). Hope Knuth is not offended.


PS: and no official SQL view support by the ORM in the Django
release yet planned?

Adrian Holovaty:
> (I've been saving this e-mail since the last sprint. Given that we're
> sprinting again this weekend, I figured it was about time to get this
> conversation started.)
>
> Let's get a definitive list of features we want in Django 1.0, and
> let's release it.
>
> I'll start with a proposed list, which no doubt has omissions. But
> first, here's a proposal for how to handle this:
>
> 1. We decide on the list of features/changes.
>
> 1.5. Once the list is final, we do NOT add to it except in case of
> an Act of God.
>
> 2. We set a deadline.
>
> 3. We work -- *primarily* on the list of features/changes, but
> allowing some time for squeezing in any other small fixes that we have
> time for.
>
> 4. Any feature that's not implemented by the deadline does NOT
> make it into version 1.0. But fear not, because version 1.0 is not the
> end of Django -- it's only the beginning!
>
> 5. Release, rejoice.
>
> The first order of business is deciding the features/changes. I'll
> kick it off with the list I've been keeping.
>
> This is just my own list, of course, and I'm sure other
> committers/contributors have other stuff. Please contribute! Just one
> important thing to note: This list is for Big Stuff only. Do not
> suggest features that would be able to be added/changed *after* the
> 1.0 release in a backwards-compatible way. The goal here is to have a
> simple, concrete list of major things that need to be done to the
> framework -- not a list of 4,000 tiny things.
>
> Without further ado, here's my list:
>
> * newforms-admin
> * queryset-refactor
> * django.newforms becomes django.forms
> * Model-level validation
> * Change django.templatetags not to use __path__ hacking
> * #3591 -- Make INSTALLED_APPS an instance, and each app an instance
> * #5361 -- File storage refactoring
> * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
>
> What am I forgetting?
>
> And, finally, a bit of a controversial statement, but...
>
> I think we ought to call the release 2.0.
>
> Jacob and I have talked in the past about how we should've called
> magic-removal version 1.0. (This ended up being 0.95.) For all intents
> and purposes, it *was* 1.0 in spirit -- it was the first major
> refactoring of several parts of the framework, and it was a point for
> me personally where I started to feel like an acceptable number of the
> legacy warts from pre-open-sourcing had been removed.
>
> So, that's one reason: philosophically, conceptually, in our minds, in
> our hearts, we're really dealing with a 2.0 product. We know Django
> rocks (and is rock-solid), and we should give it an appropriate
> number.
>
> My second reason for choosing 2.0 is, shall we say, less wholesome.
> After having endured a 2.5+ year deluge of "When is 1.0 coming out?"
> blog entries, comments, e-mails and in-person confrontations from
> people all around the world, I would find it incredibly satisfying, in
> a devilish way, to release this thing and slap a "2.0" on it. It would
> underscore the project's stability while at the same time
> demonstrating that version numbers are completely arbitrary.
>
> It'd be like Google's IPO price, which was set to the mathematical
> constant "e" -- a "we're not playing by your rules" message to Wall
> Street.
>
> Something to ponder!
>
> Adrian
>
> --
> Adrian Holovaty
> holovaty.com | djangoproject.com
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Deryck Hodge]

On Nov 30, 2007 12:33 AM, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> And, finally, a bit of a controversial statement, but...
>
> I think we ought to call the release 2.0.
>

+1

It's not an unprecedented idea across OSS projects.   We jumped from
samba 3.0.14 to 3.0.20 when we had a slew of new changes between
releases.  Granted those are dot releases, but the idea is the same.

Cheers,
deryck

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[David Reynolds]

On 30 Nov 2007, at 6:33 am, Adrian Holovaty wrote:

> My second reason for choosing 2.0 is, shall we say, less wholesome.
> After having endured a 2.5+ year deluge of "When is 1.0 coming out?"
> blog entries, comments, e-mails and in-person confrontations from
> people all around the world, I would find it incredibly satisfying, in
> a devilish way, to release this thing and slap a "2.0" on it. It would
> underscore the project's stability while at the same time
> demonstrating that version numbers are completely arbitrary.

Worth it just for this reason alone IMO ;)

-- 
David Reynolds
[EMAIL PROTECTED]



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Graham Dumpleton]

Adrian Holovaty wrote:
> (I've been saving this e-mail since the last sprint. Given that we're
> sprinting again this weekend, I figured it was about time to get this
> conversation started.)
>
> Let's get a definitive list of features we want in Django 1.0, and
> let's release it.
>
> I'll start with a proposed list, which no doubt has omissions. But
> first, here's a proposal for how to handle this:
>
> 1. We decide on the list of features/changes.
>
> 1.5. Once the list is final, we do NOT add to it except in case of
> an Act of God.
>
> 2. We set a deadline.
>
> 3. We work -- *primarily* on the list of features/changes, but
> allowing some time for squeezing in any other small fixes that we have
> time for.
>
> 4. Any feature that's not implemented by the deadline does NOT
> make it into version 1.0. But fear not, because version 1.0 is not the
> end of Django -- it's only the beginning!
>
> 5. Release, rejoice.
>
> The first order of business is deciding the features/changes. I'll
> kick it off with the list I've been keeping.
>
> This is just my own list, of course, and I'm sure other
> committers/contributors have other stuff. Please contribute! Just one
> important thing to note: This list is for Big Stuff only. Do not
> suggest features that would be able to be added/changed *after* the
> 1.0 release in a backwards-compatible way. The goal here is to have a
> simple, concrete list of major things that need to be done to the
> framework -- not a list of 4,000 tiny things.
>
> Without further ado, here's my list:
>
> * newforms-admin
> * queryset-refactor
> * django.newforms becomes django.forms
> * Model-level validation
> * Change django.templatetags not to use __path__ hacking
> * #3591 -- Make INSTALLED_APPS an instance, and each app an instance
> * #5361 -- File storage refactoring
> * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
>
> What am I forgetting?

There is probably no ticket for it, but allowing a WSGI environment
variable be used in place of DJANGO_SETTINGS_MODULE environment
variable. The intent in doing this is to get away from dependence on
what is effectively a global variable. This would perhaps allow, or at
least be a step on the way to being able to effectively host multiple
Django site instances within the one Python interpreter. This would be
better than using distinct sub interpreters in mod_python or mod_wsgi
as only have to load common modules into memory once, thus cutting
down on memory bloat when hosting a lot of sites.

I think a lot of people who are hosting a lot of related sites on the
one system would appreciate this one.

Graham
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[jj]

As a user having based some key internal applications on 0.96, which
is solid enough, and not being likely to move to 2.0 in the near
future, I'd say yes, go ahead, call it 2.0

AND

move 0.96 to 1.0 status. This might sound somewhat artificial, but
would clearly indicate that 0.96 is a version one can already trust.
Isn't the Web site already advocating 0.96 that way?

JJ.

On Nov 30, 7:33 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> (I've been saving this e-mail since the last sprint. Given that we're
> sprinting again this weekend, I figured it was about time to get this
> conversation started.)
>
> Let's get a definitive list of features we want in Django 1.0, and
> let's release it.
>
> I'll start with a proposed list, which no doubt has omissions. But
> first, here's a proposal for how to handle this:
>
> 1. We decide on the list of features/changes.
>
> 1.5. Once the list is final, we do NOT add to it except in case of
> an Act of God.
>
> 2. We set a deadline.
>
> 3. We work -- *primarily* on the list of features/changes, but
> allowing some time for squeezing in any other small fixes that we have
> time for.
>
> 4. Any feature that's not implemented by the deadline does NOT
> make it into version 1.0. But fear not, because version 1.0 is not the
> end of Django -- it's only the beginning!
>
> 5. Release, rejoice.
>
> The first order of business is deciding the features/changes. I'll
> kick it off with the list I've been keeping.
>
> This is just my own list, of course, and I'm sure other
> committers/contributors have other stuff. Please contribute! Just one
> important thing to note: This list is for Big Stuff only. Do not
> suggest features that would be able to be added/changed *after* the
> 1.0 release in a backwards-compatible way. The goal here is to have a
> simple, concrete list of major things that need to be done to the
> framework -- not a list of 4,000 tiny things.
>
> Without further ado, here's my list:
>
> * newforms-admin
> * queryset-refactor
> * django.newforms becomes django.forms
> * Model-level validation
> * Change django.templatetags not to use __path__ hacking
> * #3591 -- Make INSTALLED_APPS an instance, and each app an instance
> * #5361 -- File storage refactoring
> * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
>
> What am I forgetting?
>
> And, finally, a bit of a controversial statement, but...
>
> I think we ought to call the release 2.0.
>
> Jacob and I have talked in the past about how we should've called
> magic-removal version 1.0. (This ended up being 0.95.) For all intents
> and purposes, it *was* 1.0 in spirit -- it was the first major
> refactoring of several parts of the framework, and it was a point for
> me personally where I started to feel like an acceptable number of the
> legacy warts from pre-open-sourcing had been removed.
>
> So, that's one reason: philosophically, conceptually, in our minds, in
> our hearts, we're really dealing with a 2.0 product. We know Django
> rocks (and is rock-solid), and we should give it an appropriate
> number.
>
> My second reason for choosing 2.0 is, shall we say, less wholesome.
> After having endured a 2.5+ year deluge of "When is 1.0 coming out?"
> blog entries, comments, e-mails and in-person confrontations from
> people all around the world, I would find it incredibly satisfying, in
> a devilish way, to release this thing and slap a "2.0" on it. It would
> underscore the project's stability while at the same time
> demonstrating that version numbers are completely arbitrary.
>
> It'd be like Google's IPO price, which was set to the mathematical
> constant "e" -- a "we're not playing by your rules" message to Wall
> Street.
>
> Something to ponder!
>
> Adrian
>
> --
> Adrian Holovaty
> holovaty.com | djangoproject.com
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Bryan L. Fordham]

>
> On the issue of what to call 1.0, I like Max Battcher's idea of 
> adopting an Ubuntu-like date-based version.  Puts some useful 
> information (how old is it?) into the release name and avoids 
> preconceived notions of stability/completeness associated with .0 
> releases.
I'm +1 on that as well. Seriously, how many of us have been running 
these pre-1.0 versions in production with no real problems?


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[George Vilches]

Etienne Robillard wrote:
> 
> 
> On Nov 30, 2007 2:27 AM, Max Battcher <[EMAIL PROTECTED] 
> > wrote:
> 
> 
> On Nov 30, 2007 2:18 AM, jj <[EMAIL PROTECTED]
> > wrote:
>  > move 0.96 to 1.0 status. This might sound somewhat artificial, but
>  > would clearly indicate that 0.96 is a version one can already trust.
>  > Isn't the Web site already advocating 0.96 that way?
> 
> That might be a good idea...  backport any remaining useful fixes to
> 0.96, maybe go ahead and do the newforms -> forms rename, and not much
> more really needs to be done and call that 1.0 and everything else
> becomes 2.0...
> 
> 
> I think it would be great if Django-1.0 (and subsequent releases) be 
> backward-compatible with Django-0.96...

I think it's fair to say that with the changes already in the trunk, 
this is a lost cause.

gav

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Malcolm Tredinnick]

On Fri, 2007-11-30 at 02:27 -0500, Max Battcher wrote:
> On Nov 30, 2007 2:18 AM, jj <[EMAIL PROTECTED]> wrote:
> > move 0.96 to 1.0 status. This might sound somewhat artificial, but
> > would clearly indicate that 0.96 is a version one can already trust.
> > Isn't the Web site already advocating 0.96 that way?
> 
> That might be a good idea...  backport any remaining useful fixes to
> 0.96, maybe go ahead and do the newforms -> forms rename, and not much
> more really needs to be done and call that 1.0 and everything else
> becomes 2.0...

-1.

We're talking about doing *a* release here. Not 1.0 and then 2.0
immediately afterwards. Please don't create more work for us than
necessary.

Malcolm



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Malcolm Tredinnick]

On Fri, 2007-11-30 at 08:33 -0500, Forest Bond wrote:
> On Fri, Nov 30, 2007 at 12:33:31AM -0600, Adrian Holovaty wrote:
> > * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
> 
> Aren't there SCRIPT_NAME/PATH_INFO/etc. problems with mod_python, too?  It'd 
> be
> nice if django 1.0-based apps could be moved to different relative mount 
> points
> without changing .py files at all.  Or was this resolved when I wasn't 
> looking?

It's all the same issue. This is one of the things I'm going to review
and commit during the sprint.

Malcolm



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Forest Bond]

On Fri, Nov 30, 2007 at 12:33:31AM -0600, Adrian Holovaty wrote:
> * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff

Aren't there SCRIPT_NAME/PATH_INFO/etc. problems with mod_python, too?  It'd be
nice if django 1.0-based apps could be moved to different relative mount points
without changing .py files at all.  Or was this resolved when I wasn't looking?

-Forest
-- 
Forest Bond
http://www.alittletooquiet.net


signature.asc
Description: Digital signature

Re: Django 1.0 features -- the definitive list

[Etienne Robillard]

On Nov 30, 2007 2:27 AM, Max Battcher <[EMAIL PROTECTED]> wrote:

>
> On Nov 30, 2007 2:18 AM, jj <[EMAIL PROTECTED]> wrote:
> > move 0.96 to 1.0 status. This might sound somewhat artificial, but
> > would clearly indicate that 0.96 is a version one can already trust.
> > Isn't the Web site already advocating 0.96 that way?
>
> That might be a good idea...  backport any remaining useful fixes to
> 0.96, maybe go ahead and do the newforms -> forms rename, and not much
> more really needs to be done and call that 1.0 and everything else
> becomes 2.0...


I think it would be great if Django-1.0 (and subsequent releases) be
backward-compatible with Django-0.96...

Regards and happy sprinting!
- Etienne

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Jacob Kaplan-Moss]

On 11/30/07, Etienne Robillard <[EMAIL PROTECTED]> wrote:
> I think it would be great if Django-1.0 (and subsequent releases) be
> backward-compatible with Django-0.96...

For the most part, it will be; most of the post-0.96 changes have
been/will be "under the hood." You can see the list of changes so far
here: http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges.
Notice that the vast majority of them are relatively minor.

Jacob

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Patryk Zawadzki]

2007/11/30, Adrian Holovaty <[EMAIL PROTECTED]>:
> Without further ado, here's my list:
>
> * newforms-admin
> * queryset-refactor
> * django.newforms becomes django.forms
> * Model-level validation
> * Change django.templatetags not to use __path__ hacking
> * #3591 -- Make INSTALLED_APPS an instance, and each app an instance
> * #5361 -- File storage refactoring
> * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
>
> What am I forgetting?

For my needs:

* Extendable results of form_for_{instance,model} (sometimes you just
need to override one field in a large form)
* Sortable fields on forms extending other forms

Both are taken care of in http://code.djangoproject.com/ticket/5986

-- 
Patryk Zawadzki
PLD Linux Distribution

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Malcolm Tredinnick]

On Fri, 2007-11-30 at 16:46 +0100, Patryk Zawadzki wrote:
> 2007/11/30, Adrian Holovaty <[EMAIL PROTECTED]>:
> > Without further ado, here's my list:
> >
> > * newforms-admin
> > * queryset-refactor
> > * django.newforms becomes django.forms
> > * Model-level validation
> > * Change django.templatetags not to use __path__ hacking
> > * #3591 -- Make INSTALLED_APPS an instance, and each app an instance
> > * #5361 -- File storage refactoring
> > * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
> >
> > What am I forgetting?
> 
> For my needs:
> 
> * Extendable results of form_for_{instance,model} (sometimes you just
> need to override one field in a large form)
> * Sortable fields on forms extending other forms

This is the sort of thing where it wouldn't be a complete loss if it
didn't make it into 1.0, since form construction helpers are just that:
helpers. They don't depend on core changes and don't require core
changes to support them. Hence, somebody can just write something
outside of core that meets their purposes.

We're currently leaning more towards Joseph Kocherhans' replacement for
form_for_* (not sure how backwards compatible it will end up) and whilst
"nice to have", I don't see this as show stopper stuff for 1.0.

Let's keep a focus on things that require core changes (and hence can't
be done externally if not in the release).

Malcolm



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[[EMAIL PROTECTED]]

On Nov 30, 7:33 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> And, finally, a bit of a controversial statement, but...
>
> I think we ought to call the release 2.0.

Well, there are lots of precedents.  Emacs went from 1.12 to 13.0 at
some point, so the jump from 0.96 to 2.0 does not seem that large :)

The list looks good.  My pet peeves are trivial bugs that prevent
django-multilingual from working with clean Django checkout, but one
of them (#3275) was recently fixed in qs-rf and the other (#3434),
while still present in newforms-admin, is not as serious there as in
trunk (I did not test it yet, but it looks like you will get
javascript error instead of an exception in Python code).

On the other hand, merging qs-rf will break the multilingual machinery
anyway, so I just hope to have enough time between the qs-rf merge and
the release deadline to make django-multilingual compatible again, as
it might shake out some hidden Django bugs again.  But that is most
probably obvious to you: the list includes at least two branches with
quite low-level changes, so we need to plan a significant amount of
testing and debugging time _after_ those are merged or we will get a
traditionally buggy .0 release.

-mk

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Bob T.]

> Let's get a definitive list of features we want in Django 1.0, and
> let's release it.

Is it the consensus that multi-database isn't ready enough to be
included? If MDB is likely to have some backwards incompatible changes
then maybe it's worth considering, otherwise it doesn't really look
like a candidate to me.

> I think we ought to call the release 2.0.

That would be fun, though the Ubuntu convention would certainly
sidestep cries of "foul!".

Bob

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Graham Dumpleton]

On Dec 1, 12:37 am, "Patryk Zawadzki" <[EMAIL PROTECTED]> wrote:
> 2007/11/30, Forest Bond <[EMAIL PROTECTED]>:
>
> > On Fri, Nov 30, 2007 at 12:33:31AM -0600, Adrian Holovaty wrote:
> > > * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
>
> > Aren't there SCRIPT_NAME/PATH_INFO/etc. problems with mod_python, too?  
> > It'd be
> > nice if django 1.0-based apps could be moved to different relative mount 
> > points
> > without changing .py files at all.  Or was this resolved when I wasn't 
> > looking?
>
> Start using lighttpd + fcgi instead of Apache ;)

Or for something easier to setup than fastcgi and possibly more
reliable, stay with Apache but use mod_wsgi instead. ;-)

Graham
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Brian Rosner]

On Nov 30, 7:27 pm, Gary Wilson <[EMAIL PROTECTED]> wrote:
> Adrian Holovaty wrote:
> > Without further ado, here's my list:
>
> > * newforms-admin
> > * queryset-refactor
> > * django.newforms becomes django.forms
> > * Model-level validation
> > * Change django.templatetags not to use __path__ hacking
> > * #3591 -- Make INSTALLED_APPS an instance, and each app an instance
> > * #5361 -- File storage refactoring
> > * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
>
> > What am I forgetting?
>
> newforms in generic views and comments too.  This isn't being taken care of in
> newforms admin is it?

No this isn't being done in newforms-admin.  I would post the ticket
number, but I have created a patch with docs and tests for converting
the generic views over to newforms.  Be great if it can get some more
eyeballs and maybe get merged in tomorrow.

>
> We also have the features page made before the last 
> sprint:http://code.djangoproject.com/wiki/VersionOneFeatures
>
> On a related note, the maxlength argument is currently issuing a
> PendingDeprecationWarning.  It was talked that we would change to
> DeprecationWarning before the next release, but I think it should die before
> .0.
>
> Should we change to DeprecationWarning now and remove it before the release or
> just axe it all now?
>
> > And, finally, a bit of a controversial statement, but...
>
> > I think we ought to call the release 2.0.
>
> "The birth of Django"
> 1.910
>
> Gary
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Brian Rosner]

On Nov 30, 11:38 pm, Brian Rosner <[EMAIL PROTECTED]> wrote:
> On Nov 30, 7:27 pm, Gary Wilson <[EMAIL PROTECTED]> wrote:
>
>
>
> > Adrian Holovaty wrote:
> > > Without further ado, here's my list:
>
> > > * newforms-admin
> > > * queryset-refactor
> > > * django.newforms becomes django.forms
> > > * Model-level validation
> > > * Change django.templatetags not to use __path__ hacking
> > > * #3591 -- Make INSTALLED_APPS an instance, and each app an instance
> > > * #5361 -- File storage refactoring
> > > * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
>
> > > What am I forgetting?
>
> > newforms in generic views and comments too.  This isn't being taken care of 
> > in
> > newforms admin is it?
>
> No this isn't being done in newforms-admin.  I would post the ticket
> number, but I have created a patch with docs and tests for converting
> the generic views over to newforms.  Be great if it can get some more
> eyeballs and maybe get merged in tomorrow.

Er, I meant to say that I can't post the ticket since the site is down
for maintenance and that I have created a patch ;)

>
>
>
> > We also have the features page made before the last 
> > sprint:http://code.djangoproject.com/wiki/VersionOneFeatures
>
> > On a related note, the maxlength argument is currently issuing a
> > PendingDeprecationWarning.  It was talked that we would change to
> > DeprecationWarning before the next release, but I think it should die before
> > .0.
>
> > Should we change to DeprecationWarning now and remove it before the release 
> > or
> > just axe it all now?
>
> > > And, finally, a bit of a controversial statement, but...
>
> > > I think we ought to call the release 2.0.
>
> > "The birth of Django"
> > 1.910
>
> > Gary
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[SmileyChris]

On Dec 1, 5:24 am, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
> On the issue of what to call 1.0, I like Max Battcher's idea of adopting an
> Ubuntu-like date-based version.  Puts some useful information (how old is
> it?) into the release name and avoids preconceived notions of
> stability/completeness associated with .0 releases.

+1

While 2.0 sounds like we'd be "making a statement", this sounds more
sensible.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Eugene Lazutkin]

+1. I agree with Simon's reasoning.


Simon Willison wrote:
> On Nov 30, 6:33 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
>> I think we ought to call the release 2.0.
> 
> I'm -0.5 on this (if that's possible). I understand the thinking
> behind it, but "1.0" isn't an arbitrary version number - it has a very
> specific meaning: "the APIs are frozen, it's safe to build things
> without worrying that backwards compatibility will be broken". That's
> what we've been telling people for the past couple of years, and as a
> result I feel it would be odd to use 2.0 to make the statement that
> version numbers are meaningless after all.
> 
> I think that the release of v1.0 combined with the publication of the
> Django Book will result in a serious uptick in interest in the project
> (and that's not saying that there isn't plenty of interest already). I
> wouldn't want to see some of that interest diverted by confusion over
> version numbers.
> 
> Cheers,
> 
> Simon
> > 
> 


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[oggie rob]

On Nov 29, 10:33 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> Without further ado, here's my list:
>
> * newforms-admin
> * queryset-refactor
> * django.newforms becomes django.forms
> * Model-level validation
> * Change django.templatetags not to use __path__ hacking
> * #3591 -- Make INSTALLED_APPS an instance, and each app an instance
> * #5361 -- File storage refactoring
> * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
>
> What am I forgetting?

Good choices, Adrian. I talked about this with you guys last sprint
(sorry by the way for missing this one) and I think these hit the
spot. Various branches may have to scramble a little to get up to date
but I think that will give them a better point of reference than "the
last time we branched". Also these are clearly backwards incompatible
- good to get those out of the way and make the upgrade path easier
for those starting with the next major version, and add the less-
incompatible changes later.

>
> And, finally, a bit of a controversial statement, but...
>
> I think we ought to call the release 2.0.
>

Well Rails is about to release 2.0... oops, did I say that out loud?!

Great stuff!
 -rob
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Gábor Farkas]

Simon Willison wrote:
> I'd love to have a simpler alternative to the regexp method that is
> more friendly for developers who haven't fully grokked regular
> expression syntax yet.

while i agree that simplifying things is always a good idea, i think
that "developers who haven't fully grokked regular expression syntax
yet" should learn them as soon as possible :-)

gabor

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[David Larlet]

Le 30 nov. 07 à 07:33, Adrian Holovaty a écrit :
>
> Let's get a definitive list of features we want in Django 1.0, and
> let's release it.

Just great.
>
> Without further ado, here's my list:
>
> * newforms-admin
> * queryset-refactor
> * django.newforms becomes django.forms
> * Model-level validation
> * Change django.templatetags not to use __path__ hacking
> * #3591 -- Make INSTALLED_APPS an instance, and each app an instance
> * #5361 -- File storage refactoring
> * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
>
> What am I forgetting?

Maybe use request.DATA instead of POST as discussed in #5682? It's  
backward compatible and not a Big Stuff but can require a lot of  
changes if it becomes the right way to do®.

David


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Thomas Güttler]

> Without further ado, here's my list:
> ...

My whish: Use DRY (Don't repeat yourself) for the documentation:
Join both into one:
http://www.djangoproject.com/documentation/
http://www.djangobook.com/

And make the documentation (incl. API doc) available trough the development 
server. Either in admin or as own application.

 Thomas Güttler

-- 
Thomas Güttler, http://www.tbz-pariv.de/ 
Bernsdorfer Str. 210-212, 09126 Chemnitz, Tel.: 0371/5347-917
TBZ-PARIV GmbH  Geschäftsführer: Dr. Reiner Wohlgemuth
Sitz der Gesellschaft: Chemnitz Registergericht: Chemnitz HRB 8543

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[James Bennett]

On 11/30/07, Simon Willison <[EMAIL PROTECTED]> wrote:
> It's probably too big a feature to start talking about now, but I'd be
> really interested in seeing Django applications (in particular the
> URLconf part) unified with the concept of a Django view, so a Django
> application is a callable that takes a request object and returns a
> response - and in fact an entire Django deployment can be boiled down
> to that. This has a number of advantages:

At that point I'd wonder why Django had any machinery for
request/response processing, middleware, etc., given that what you're
describing is more neatly handled by just writing a WSGI application
and taking advantage of the existing tools.

I'd much prefer to have our WSGI issues straightened out so that
Django can be a first-class WSGI citizen, and leave dispatch and
request/response within the framework as they are.

-- 
"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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Russell Keith-Magee]

On Nov 30, 2007 3:33 PM, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> Let's get a definitive list of features we want in Django 1.0, and
> let's release it.

+1

> I'll start with a proposed list, which no doubt has omissions. But
> first, here's a proposal for how to handle this:
...
> 2. We set a deadline.

This is the only one that worries me... as much as I would like to
make the v1.0 hawks go away by saying "no later than X", I think the
better approach is to set a conservative set of goal features, rather
than a chronological deadline. Hypothetical extreme case - we set up a
feature list, and set a deadline for 1 July 2008. Then all the core
developers get distracted on non-Django work, 1 July comes around, and
we still haven't merged newforms-admin. At this point, I don't care
what the date is - a v1.0 without newforms-admin would be a waste of
time.

> What am I forgetting?

That looks like a pretty comprehensive list to me. I can only think of
2 items that aren't present:

1) Model inheritance.
2) #2070 - streaming uploads.

My reasoning for (1) is much the same as James. From a purely
technical perspective, inheritance/subclassing/abstract base classes
could probably be added post 1.0 without any backwards incompatiblilty
issues. However, the OneToOneField has been marked as 'don't use this,
there's something better coming' for almost as long as I can remember;
since the point of the v1 release is to establish the core APIs that
we are happy with, this is probably something we should resolve.

As for #2070 - it has a lot of followers (currently 32 names on the CC list);
I haven't had a look at this patch for a while, so I don't remember
the extent to which it could be integrated post v1. However, it's one
of those tickets that (a) has a lot of interest and (b) has an
apparently working implementation, so IMHO its worth the effort to
include it.

> And, finally, a bit of a controversial statement, but...
>
> I think we ought to call the release 2.0.

While I can appreciate the 'stick it to them' sentiment, I don't like
the way that this conflicts with the message that we have been sending
for quite some time - that v1.0 is when we will stabilize our APIs. I
for one don't want to have to answer the deluge of "Huh? When was 1.0
released?" questions from people that don't get the joke.

Russ %-)

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Nick]

> And, finally, a bit of a controversial statement, but...
>
> I think we ought to call the release 2.0.
>

+0 from me.  I've never set much store by version numbers, but I
suppose
2.0 will suggest a bigger leap forward to most people - and there's
a lot of good stuff on that list.


Nick
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Panos]

Having major releases include a nickname might be nice too (like
Ubuntu & OS X).

We could use Reinhardt's album titles, ie:

"Django 2.0 - Paris 1945", "I'm using the Paris 1945 version", etc.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Jacob Kaplan-Moss]

On 12/3/07, Thomas Güttler <[EMAIL PROTECTED]> wrote:
> Join both into one:
> http://www.djangoproject.com/documentation/
> http://www.djangobook.com/

This won't happen, for a bunch of reasons including the fact that the
licenses aren't compatible and the release schedules are drastically
different.

> And make the documentation (incl. API doc) available trough the development
> server. Either in admin or as own application.

While this is a good idea (and certainly on my list), it's very much
*not* something that should block releasing 1.0. Adding documentation
in 1.1 or 2.0 or 7.56 doesn't cause any backwards incompatibilities.

Folks, we need to think very carefully about the features we put on
the 1.0 list. The goal of 1.0 is forward API stability, not
feature-completion. Getting a release out in a timely manner means
that we'll all need to sacrifice our personal wishlist to a more
pragmatic -- and smaller -- feature set.

Jacob

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[[EMAIL PROTECTED]]

For some unknown reason I am in love with this suggestion.

On Dec 3, 9:52 am, Panos <[EMAIL PROTECTED]> wrote:
> Having major releases include a nickname might be nice too (like
> Ubuntu & OS X).
>
> We could use Reinhardt's album titles, ie:
>
> "Django 2.0 - Paris 1945", "I'm using the Paris 1945 version", etc.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Simon Willison]

On 3 Dec 2007, at 08:15, James Bennett wrote:

> At that point I'd wonder why Django had any machinery for
> request/response processing, middleware, etc., given that what you're
> describing is more neatly handled by just writing a WSGI application
> and taking advantage of the existing tools.

Because WSGI is a horrible API for developers. I'd love to see Django  
request/response become a simple developer-friendly wrapper around  
WSGI, provided we gained rather than lost flexibility and power in  
the process.

I'd like to see the distance between a Django application (or a  
Django view) and WSGI as small as possible. Imagine if you could drop  
a Django view in to any WSGI container just by applying a WSGI-to- 
Django-view wrapper of some sort. Or, imagine taking a WSGI  
application, wrapping it up as a Django view and deploying it  
straight in to a Django URL configuration.

Cheers,

Simon

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[David Cramer]

I just want to bring this up again, because Model Inheritance is a
HUGE thing...

I have not seen any final discussion on how it's going to work (http://
code.djangoproject.com/wiki/ModelInheritance). Last I heard it was
still up in the air. If there are features that are unsure of, I don't
see how they can make a timely 1.0 release.

On Dec 3, 3:19 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On Nov 30, 2007 3:33 PM, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
>
>
> > Let's get a definitive list of features we want in Django 1.0, and
> > let's release it.
>
> +1
>
>
>
> > I'll start with a proposed list, which no doubt has omissions. But
> > first, here's a proposal for how to handle this:
> ...
> > 2. We set a deadline.
>
> This is the only one that worries me... as much as I would like to
> make the v1.0 hawks go away by saying "no later than X", I think the
> better approach is to set a conservative set of goal features, rather
> than a chronological deadline. Hypothetical extreme case - we set up a
> feature list, and set a deadline for 1 July 2008. Then all the core
> developers get distracted on non-Django work, 1 July comes around, and
> we still haven't merged newforms-admin. At this point, I don't care
> what the date is - a v1.0 without newforms-admin would be a waste of
> time.
>
> > What am I forgetting?
>
> That looks like a pretty comprehensive list to me. I can only think of
> 2 items that aren't present:
>
> 1) Model inheritance.
> 2) #2070 - streaming uploads.
>
> My reasoning for (1) is much the same as James. From a purely
> technical perspective, inheritance/subclassing/abstract base classes
> could probably be added post 1.0 without any backwards incompatiblilty
> issues. However, the OneToOneField has been marked as 'don't use this,
> there's something better coming' for almost as long as I can remember;
> since the point of the v1 release is to establish the core APIs that
> we are happy with, this is probably something we should resolve.
>
> As for #2070 - it has a lot of followers (currently 32 names on the CC list);
> I haven't had a look at this patch for a while, so I don't remember
> the extent to which it could be integrated post v1. However, it's one
> of those tickets that (a) has a lot of interest and (b) has an
> apparently working implementation, so IMHO its worth the effort to
> include it.
>
> > And, finally, a bit of a controversial statement, but...
>
> > I think we ought to call the release 2.0.
>
> While I can appreciate the 'stick it to them' sentiment, I don't like
> the way that this conflicts with the message that we have been sending
> for quite some time - that v1.0 is when we will stabilize our APIs. I
> for one don't want to have to answer the deluge of "Huh? When was 1.0
> released?" questions from people that don't get the joke.
>
> Russ %-)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Malcolm Tredinnick]

On Mon, 2007-12-03 at 11:03 -0800, David Cramer wrote:
> I just want to bring this up again, because Model Inheritance is a
> HUGE thing...
> 
> I have not seen any final discussion on how it's going to work (http://
> code.djangoproject.com/wiki/ModelInheritance). Last I heard it was
> still up in the air. If there are features that are unsure of, I don't
> see how they can make a timely 1.0 release.

Then you haven't searched the archives closely enough. Since this is the
second time today this has come up, I'll post the summary of what's
going to happen in a couple of days, after I'm back in Australia and
recovered from the travel. It's been discussed ad infinitum with some
reasonable agreement in the past.

Malcolm




--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[James Bennett]

On 12/3/07, Simon Willison <[EMAIL PROTECTED]> wrote:
> I'd like to see the distance between a Django application (or a
> Django view) and WSGI as small as possible. Imagine if you could drop
> a Django view in to any WSGI container just by applying a WSGI-to-
> Django-view wrapper of some sort. Or, imagine taking a WSGI
> application, wrapping it up as a Django view and deploying it
> straight in to a Django URL configuration.

I've got some half-assed code for this lying around actually; I'd
envisioned something like 'django.views.generic.wsgi.wsgi_application'
being a way to simply drop any WSGI application into a Django URLConf.


-- 
"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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Marty Alchin]

On Dec 3, 2007 2:26 PM, James Bennett <[EMAIL PROTECTED]> wrote:
> I've got some half-assed code for this lying around actually; I'd
> envisioned something like 'django.views.generic.wsgi.wsgi_application'
> being a way to simply drop any WSGI application into a Django URLConf.

I don't know much about WSGI, but Malcolm and I have had some
discussion about some minor changes to URL resolution that would make
something like this a wee bit nicer. I don't have a link to it
offhand, but I had a need for something a little different than normal
when I was working out a Netvibes widget app, and it sounds like there
might be some overlap. Probably a bit off-topic for this thread,
though.

-Gul

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Adrian Holovaty]

On Dec 3, 2007 9:52 AM, Panos <[EMAIL PROTECTED]> wrote:
> Having major releases include a nickname might be nice too (like
> Ubuntu & OS X).
>
> We could use Reinhardt's album titles, ie:
>
> "Django 2.0 - Paris 1945", "I'm using the Paris 1945 version", etc.

A vehement "no, no, no." Nicknames like this are way too confusing,
and they offer no value other than cutesiness.

Adrian

-- 
Adrian Holovaty
holovaty.com | djangoproject.com

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[David Cramer]

I'm also -1 on the strange names -- especially something like "Paris
1945" :P

On Dec 3, 11:51 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> On Dec 3, 2007 9:52 AM, Panos <[EMAIL PROTECTED]> wrote:
>
> > Having major releases include a nickname might be nice too (like
> > Ubuntu & OS X).
>
> > We could use Reinhardt's album titles, ie:
>
> > "Django 2.0 - Paris 1945", "I'm using the Paris 1945 version", etc.
>
> A vehement "no, no, no." Nicknames like this are way too confusing,
> and they offer no value other than cutesiness.
>
> Adrian
>
> --
> Adrian Holovaty
> holovaty.com | djangoproject.com
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[jj]

Don't overlook the marketing aspect. Trust disappears without visible
progress. Visible progress comes from version numbers. The more often,
the better. 0.96 has been out 9 months already. You mention an extra
8-9 months for 2.0/1.0 (from what I understand in another thread).
Experience says it generally takes longer. It wouldn't be fair to you
or the community if people moved elsewhere in the meantime.

Don't get me wrong. I'm not criticizing the work that has been done or
is currently being done. 0.96 is a tremendous release already and I
know you're all hard work on even stronger stuff. It's just about
saying, yes, there's more to come (2.0 or 1.5), but 1.0 (i.e. 0.96) is
good enough already.

Or maybe 2.0 is just so close already? (If so I'd say don't add more,
just complete what's in the trunk (and key) and ship; then make an
another release with the new stuff that is being discussed in this
thread.)

JJ.


On Nov 30, 3:13 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Fri, 2007-11-30 at 02:27 -0500, Max Battcher wrote:
> > On Nov 30, 2007 2:18 AM, jj <[EMAIL PROTECTED]> wrote:
> > > move 0.96 to1.0status. This might sound somewhat artificial, but
> > > would clearly indicate that 0.96 is a version one can already trust.
> > > Isn't the Web site already advocating 0.96 that way?
>
> > That might be a good idea...  backport any remaining useful fixes to
> > 0.96, maybe go ahead and do the newforms -> forms rename, and not much
> > more really needs to be done and call that1.0and everything else
> > becomes 2.0...
>
> -1.
>
> We're talking about doing *a* release here. Not1.0and then 2.0
> immediately afterwards. Please don't create more work for us than
> necessary.
>
> Malcolm
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[bobj]

Simon - These are GREAT!!! Ideas. The regular expression based URL
dispatching  replacement has been something I personally have been
thinking about for some time.  I would be interested in helping with
this If you put together a proposal. One URL implementation worth
considering is "Routes" ( http://routes.groovie.org ). I have used
Routes for web applications and I think it is easy to grok. Have you
taken a look at Routes?

BobJ

On Nov 30, 7:50 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> On Nov 30, 6:33 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
>
> > What am I forgetting?
>
> It's probably too big a feature to start talking about now, but I'd be
> really interested in seeing Django applications (in particular the
> URLconf part) unified with the concept of a Django view, so a Django
> application is a callable that takes a request object and returns a
> response - and in fact an entire Django deployment can be boiled down
> to that. This has a number of advantages:
>
> 1. At the moment, middleware applies globally to the whole site. This
> is bad: often you'll want a piece of middleware to apply just to one
> or two of the applications that a site is composed of. If views and
> applications (and projects) had a unified API then middleware could be
> redefined to apply at any level of the stack. View middleware wouldn't
> make so much sense here, but Request and Response middleware would.
> 2. We always said that the regular expression based URL dispatching
> should be replaceable by other methods if required. Having url
> dispatch as just another view function would give us that for free.
> I'd love to have a simpler alternative to the regexp method that is
> more friendly for developers who haven't fully grokked regular
> expression syntax yet.
>
> If there's enough interest in the DEP idea I'd be happy to write up
> this proposal more formally.
>
> Cheers,
>
> Simon
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Simon Willison]

On 4 Dec 2007, at 13:26, bobj wrote:

> Simon - These are GREAT!!! Ideas. The regular expression based URL
> dispatching  replacement has been something I personally have been
> thinking about for some time.  I would be interested in helping with
> this If you put together a proposal. One URL implementation worth
> considering is "Routes" ( http://routes.groovie.org ). I have used
> Routes for web applications and I think it is easy to grok. Have you
> taken a look at Routes?

I like Routes in principle, but the way it has the concept of a  
"controller" baked in to it didn't sit very well with me. I can't  
imagine it would be hard to use it without controllers though.

I'm generally pretty happy with regular expressions, but I watched  
Scott Guthrie's presentation on the ASP.NET MVC framework a few weeks  
ago (it's really interesting, they've taken a bunch of ideas from  
Django and it gets name-checked in the presentation) and one of the  
things he noted is that there are developers (especially in the  
Microsoft ecosystem) who never really got comfortable with regexps. I  
don't want those people to be turned away from Django on the first  
page of the tutorial. He also described the ASP.NET MVC syntax for  
URLs, which looks like this:

search/[query]
product/[id]

http://weblogs.asp.net/scottgu/archive/2007/12/03/asp-net-mvc- 
framework-part-2-url-routing.aspx

While I personally prefer the power of regexps, I can see how the  
above would make it much easier for developers just beginning to get  
their feet wet with Django. We can always enlighten them with the  
power of regular expressions once they're hooked. If URL handling is  
interchangeable we can have the best of both worlds. Incidentally,  
allowing URL logic to be swapped out was an initial design goal back  
when we put the URL stuff together - we were worried about  
performance, but when we benchmarked it turned out that Python can  
run through a list of a hundred or so regular expressions in less  
than 0.01 seconds.

Cheers,

Simon

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Ned Batchelder]

I would like to see a replacement for the regex scheme as well, but not 
because I am uncomfortable with regexes.  I think the typical regex for 
a URL is noisy: it's hard to see the intent of the expression.  Most URL 
regexes follow some very well-defined patterns, and we don't have a way 
to express them other than to "compile them down" to regexes.  Sometimes 
you need the full power, but usually, your URL consists of fixed parts 
and variable parts separated by slashes.  The variable parts are often 
numbers, or slugs, and need to be given names.  Being able to express 
that succinctly would solve most people's URL matching.

I don't have a suggestion for a replacement, and I don't think it needs 
to be on the 1.0 list (since it can be added without breaking backward 
compatibility), but I think it would be a big plus.

--Ned.
http://nedbatchelder.com/blog

Simon Willison wrote:
> On 4 Dec 2007, at 13:26, bobj wrote:
>
>   
>> Simon - These are GREAT!!! Ideas. The regular expression based URL
>> dispatching  replacement has been something I personally have been
>> thinking about for some time.  I would be interested in helping with
>> this If you put together a proposal. One URL implementation worth
>> considering is "Routes" ( http://routes.groovie.org ). I have used
>> Routes for web applications and I think it is easy to grok. Have you
>> taken a look at Routes?
>> 
>
> I like Routes in principle, but the way it has the concept of a  
> "controller" baked in to it didn't sit very well with me. I can't  
> imagine it would be hard to use it without controllers though.
>
> I'm generally pretty happy with regular expressions, but I watched  
> Scott Guthrie's presentation on the ASP.NET MVC framework a few weeks  
> ago (it's really interesting, they've taken a bunch of ideas from  
> Django and it gets name-checked in the presentation) and one of the  
> things he noted is that there are developers (especially in the  
> Microsoft ecosystem) who never really got comfortable with regexps. I  
> don't want those people to be turned away from Django on the first  
> page of the tutorial. He also described the ASP.NET MVC syntax for  
> URLs, which looks like this:
>
> search/[query]
> product/[id]
>
> http://weblogs.asp.net/scottgu/archive/2007/12/03/asp-net-mvc- 
> framework-part-2-url-routing.aspx
>
> While I personally prefer the power of regexps, I can see how the  
> above would make it much easier for developers just beginning to get  
> their feet wet with Django. We can always enlighten them with the  
> power of regular expressions once they're hooked. If URL handling is  
> interchangeable we can have the best of both worlds. Incidentally,  
> allowing URL logic to be swapped out was an initial design goal back  
> when we put the URL stuff together - we were worried about  
> performance, but when we benchmarked it turned out that Python can  
> run through a list of a hundred or so regular expressions in less  
> than 0.01 seconds.
>
> Cheers,
>
> Simon
>
> >
>
>   

-- 
Ned Batchelder, http://nedbatchelder.com


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[James Bennett]

On 12/4/07, Ned Batchelder <[EMAIL PROTECTED]> wrote:
>  I don't have a suggestion for a replacement, and I don't think it needs to
> be on the 1.0 list (since it can be added without breaking backward
> compatibility), but I think it would be a big plus.

While I actually like the power and flexibility of regex-based
dispatch, I wouldn't mind seeing something like Joe Gregorio's URI
Templates[1] as an option. That would offer a nice balance between
power and conceptual simplicity, and once it (hopefully) becomes a
published RFC it'd be nice to support the standard.

[1] http://bitworking.org/news/URI_Templates

-- 
"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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Waylan Limberg]

On Dec 4, 2007 10:31 PM, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On 12/4/07, Ned Batchelder <[EMAIL PROTECTED]> wrote:
> >  I don't have a suggestion for a replacement, and I don't think it needs to
> > be on the 1.0 list (since it can be added without breaking backward
> > compatibility), but I think it would be a big plus.
>
> While I actually like the power and flexibility of regex-based
> dispatch, I wouldn't mind seeing something like Joe Gregorio's URI
> Templates[1] as an option. That would offer a nice balance between
> power and conceptual simplicity, and once it (hopefully) becomes a
> published RFC it'd be nice to support the standard.
>
> [1] http://bitworking.org/news/URI_Templates
>

Selector[1], a raw WSGI middleware for url dispatching, uses something
almost exactly like this. Although, there are a few things we
obviously wouldn't want, it provides a decent starting point. I'd
suggest ignoring all the "updates" and scrolling down to the basic
tutorial at the bottom of the page for the general idea.

[1]: http://lukearno.com/projects/selector/



-- 

Waylan Limberg
[EMAIL PROTECTED]

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Adrian Holovaty]

On Dec 4, 2007 10:17 PM, Waylan Limberg <[EMAIL PROTECTED]> wrote:
> Selector[1], a raw WSGI middleware for url dispatching, uses something
> almost exactly like this. Although, there are a few things we
> obviously wouldn't want, it provides a decent starting point. I'd
> suggest ignoring all the "updates" and scrolling down to the basic
> tutorial at the bottom of the page for the general idea.

This is getting off-topic, but I've had an implementation of
Django-URLconfs-as-a-WSGI-application lying around in my home
directory for probably 6 months. I designed it to honor the
routing_args specification
(http://wsgi.org/wsgi/Specifications/routing_args) so that people
could drop in Selector and Routes if they so desired. I should clean
it up and post it to the list...

Adrian

-- 
Adrian Holovaty
holovaty.com | djangoproject.com

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Jannis Leidel]

Am 30.11.2007 um 07:33 schrieb Adrian Holovaty:

> * newforms-admin
> * queryset-refactor
> * django.newforms becomes django.forms
> * Model-level validation
> * Change django.templatetags not to use __path__ hacking
> * #3591 -- Make INSTALLED_APPS an instance, and each app an instance
> * #5361 -- File storage refactoring
> * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
>
> What am I forgetting?

Please add support for loading Django apps from PythonEggs in  
preparation of the hot club of france.
Ticket #6080 includes a patch with documentation and is backwards- 
compatible.

Best,
Jannis

--
jannisleidel.com

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Malcolm Tredinnick]

On Sat, 2007-12-08 at 01:03 -0800, Antonio Cangiano wrote:
> On Nov 30, 1:33 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> > I think we ought to call the release 2.0.
> 
> Adrian, marketing matters. :)
> How about releasing 1.0 now, 1.2 in a month or so, and then 2.0 when
> all the features listed above will be implemented?

Because, as you say, marketing matters. Releasing code that forces
people to do reasonably fiddly upgrades multiple times in the course of
a couple of months is unreasonable. Given that we're only talking about
a few months, at worst, in any case, rushing to release something just
so that we can say we've released something, no matter how unready, is
unprofessional.

Malcolm

-- 
Why be difficult when, with a little bit of effort, you could be
impossible. 
http://www.pointy-stick.com/blog/


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Antonio Cangiano]

On Nov 30, 1:33 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> I think we ought to call the release 2.0.

Adrian, marketing matters. :)
How about releasing 1.0 now, 1.2 in a month or so, and then 2.0 when
all the features listed above will be implemented?

Cheers,
Antonio
--
Antonio Cangiano
http://antoniocangiano.com
http://math-blog.com
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Kevin Menard]

On Nov 30, 2007, at 8:54 PM, Simon Willison wrote:

>
> On Nov 30, 6:33 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
>> I think we ought to call the release 2.0.
>
> I'm -0.5 on this (if that's possible). I understand the thinking
> behind it, but "1.0" isn't an arbitrary version number - it has a very
> specific meaning: "the APIs are frozen, it's safe to build things
> without worrying that backwards compatibility will be broken". That's
> what we've been telling people for the past couple of years, and as a
> result I feel it would be odd to use 2.0 to make the statement that
> version numbers are meaningless after all.

Apologies for chiming in late.  I agree with Simon's sentiments.   
Moreover, if the point is that version numbers mean nothing, which is  
fine, then what mechanism is used to convey API compatibility between  
releases?

Shifting to a more personal stance, I never cared much for the term  
"Web 2.0".  It seems too gimmicky.  That's largely the impression I  
get with a Django 2.0 without a prior Django 1.0.

-- 
Kevin

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Simon Willison]

On 8 Dec 2007, at 20:14, Kevin Menard wrote:

> Shifting to a more personal stance, I never cared much for the term
> "Web 2.0".  It seems too gimmicky.  That's largely the impression I
> get with a Django 2.0 without a prior Django 1.0.

The other problem with Django 2.0 is that Rails just released their  
2.0 - which means that a Django release will look like an attempt to  
catch up on the version number - obviously not the case. If we wanted  
to make a statement about Django's maturity that statement could be  
equally well served by jumping straight to 1.5. This would also  
maintain the meaningfulness of version 1.0 - once past 1.0, backwards  
compatibility with the APIs is guaranteed.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Bryan Veloso]

> What am I forgetting?

This is a completely personal and probably selfish desire, but I'd
love to see the comments system rewrite in there. It's been on that
informal wiki-list ever since I started using Django.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Rob Hudson]

Would it be too much to start thinking about marketing for the 1.0
release?  By marketing, I mean, screencasts, t-shirts, coffee mugs.
Possibly a not-for-profit entity to pipe whatever proceeds or
donations through to help support Django coding, or have paid
bounties, etc.

IIRC, some of these things have always been shelved for the 1.0 release.

-Rob

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---