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, 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?")
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."
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/
> 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
da...@reynoldsfamily.org.uk
+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
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
Start using lighttpd + fcgi instead of Apache ;)
--
Patryk Zawadzki
PLD Linux Distribution
It's all the same issue. This is one of the things I'm going to review
and commit during the sprint.
Malcolm
-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
> +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/
That might be a good idea... backport any remaining useful fixes to
On Nov 30, 2007 2:18 AM, jj <jjmo...@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?
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's fair to say that with the changes already in the trunk,
this is a lost cause.
gav
> 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/
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
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
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
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 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).
[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.
(ducks for cover behind fire-retardant suit ;)
> 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?
it's a classified ads service that
shows on a map where the seller is
(think craigslist + google maps)
plus it's 100% free :)
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 Holovaty wrote:
> On Nov 30, 2007 11:56 AM, Derek Anderson <pub...@kered.org> 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
>
--
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
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
<what do we call it>.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
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
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
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
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."
+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 %-)
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
> 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
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
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
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
> 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
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
way...@gmail.com
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...
> * 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
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/
>
> On Nov 30, 6:33 am, "Adrian Holovaty" <holov...@gmail.com> 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
> 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.
IIRC, some of these things have always been shelved for the 1.0 release.
-Rob