(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
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?")
On 11/30/07, Adrian Holovaty <holov...@gmail.com> 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."
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" <holov...@gmail.com> 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
On Nov 30, 2007 2:18 AM, jj <jjmor...@gmail.com> 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...
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.
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.
On Nov 30, 2007 12:33 AM, Adrian Holovaty <holov...@gmail.com> 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.
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.
<small>PS: and no official SQL view support by the ORM in the Django
release yet planned?</small>
> (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
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?
