The road to 1.0

[Jacob Kaplan-Moss]

Howdy, all --

Django's been out as an unofficial pre-release for almost a month
now, and it's about time to wrap things up to roll a 1.0 release.

We've decided that Django, like Python itself, should put a very high
priority on backwards compatibility, so now's the time to make any
large architectural changes (like #65 and #122). We've created a
"Version 1.0" milestone (see http://code.djangoproject.com/roadmap),
so if you'd like to nominate a feature for inclusion in version 1.0,
please feel free to assign a ticket to that milestone. If it's
something you feel is "controversial" in any way, please post a
message to this list with your proposal. As always, code speaks
louder than words: proposals with patches are much easier for us to
evaluate.

Since we'd like to get started on our plan for world domination
quickly, please try to make any proposals for features of 1.0 by the
end of the week; I'd like to set a release schedule based on those
features early next week.

Thanks!

Jacob

[espen.g...@gmail.com]

> Since we'd like to get started on our plan for world domination
> quickly, please try to make any proposals for features of 1.0 by the
> end of the week; I'd like to set a release schedule based on those
> features early next week.

I just think that #12 should be a part of milestone 1.0

Espen Grindhaug (EspenG @ irc)

[Krzysztof Drozd]

#1 && #41 && #65should be a part of milestone 1.0
Krzysztof Drozd

[Jacob Kaplan-Moss]

On Aug 2, 2005, at 6:55 PM, Krzysztof Drozd wrote:
> #1 && #41 && #65should be a part of milestone 1.0

On Aug 2, 2005, at 6:41 PM, es...@grindhaug.org wrote:
> I just think that #12 should be a part of milestone 1.0

I've added #1 and #65 to version 1.0. I'm not sure about #12 and
#41; they both seem like quite a bit of work for minimal payoff, and
we're aiming to get 1.0 out the door sooner, rather than later. Is
it going to seriously cramp anyone's style if these are 1.1 (or
1.0.1) features?

Of course, if anyone wants to submit patches (or volunteer to write
them over the next few weeks), I can virtually guarantee that these
will make it into 1.0...

Jacob

[maney]

I have no idea if this is practical, but from my own experience I
suspect it will affect the interface and so it's a "now or not until
version 2" issue. I would dearly love to see the limitation that
primary keys (and, therefore, foreign keys) can be only single columns
removed. It is, I know, something that's unlikely to come up in the
CMS sphere; even in more general database-centered apps I find this to
be only occasionally necessary. But when you need it, because the data
wants to be that way, the workarounds tend to be ugly in their effect
on the model.

I've been away from things Django for a little while, in part because
Adrian didn't make it sound as though this were likely, but then that
was back in the first week when things were more than hectic. So
before it's too late to consider - I hope - I'm raising it once again.

[Krzysztof Drozd]

ok then just #1 and #65.

[Jason Huggins]

1) I would like to see django-admin.py methods 'startapp' and
'startproject' renamed to 'createapp' and 'createproject'. "start"
implies 'starting the server'... too similar to 'runserver', I think.

2) Provide a standard convention for where people should put their
tests (unit, functional, and maybe browser UI), and generated API
documentation (like from Epydoc). Perhaps <myproject>/test and
<myproject>/doc. When generating models, you could generate some basic
core unit and functional tests for users to 'embrace and exptend' later
on.

3) Also, if going live with "1.0" means "backwards compatibility is now
job #1"... you *really* need a full suite of unit and functional tests
to automatically ensure Django doesn't break any promises in later
releases. Can you call it 1.0 without those tests? Maybe. But you
shouldn't release 1.1 or 1.2 without them, for sure.

4) Let the required Django environment variables live in a config
file... Then the admin script or other bootprocess can set the
environment variable for you and move on.

5) Add a "scripts" folder as in <myproject>/scripts with autogenerated
batch or shell scripts for starting the server, with nothing more
required than a "double-click" of the script after the createproject
and init steps. It should be able to find and set all required django
and python paths relative to that folder.

5b) Create an alias script to django-admin.py inside the above scripts
folder. Again, with relative paths in effect, you wouldn't need to set
the environment variable manually or add it to the command line
manually...

(Most of these are not 'architectural' changes, but they sure would be
nice to have in there when your newbie techie journalists check out
this new "Django 1.0" thing and start playing with the framework.

[Carlo C8E Miron]

hi all,
just a (+1 all), but i think that these are really important improvements.

2005/8/4, Jason Huggins <jrhu...@gmail.com>:

>
> 1) I would like to see django-admin.py methods 'startapp' and
> 'startproject' renamed to 'createapp' and 'createproject'. "start"
> implies 'starting the server'... too similar to 'runserver', I think.

+1, seems trivial

> 2) Provide a standard convention for where people should put their
> tests (unit, functional, and maybe browser UI), and generated API
> documentation (like from Epydoc). Perhaps <myproject>/test and
> <myproject>/doc. When generating models, you could generate some basic
> core unit and functional tests for users to 'embrace and exptend' later
> on.

+1, also trivial

> 3) Also, if going live with "1.0" means "backwards compatibility is now
> job #1"... you *really* need a full suite of unit and functional tests
> to automatically ensure Django doesn't break any promises in later
> releases. Can you call it 1.0 without those tests? Maybe. But you
> shouldn't release 1.1 or 1.2 without them, for sure.

+1, but not trivial at all. maybe this can be a task for 1.1...

> 4) Let the required Django environment variables live in a config
> file... Then the admin script or other bootprocess can set the
> environment variable for you and move on.

+2. ahem, i mean +1 :)

> 5) Add a "scripts" folder as in <myproject>/scripts with autogenerated
> batch or shell scripts for starting the server, with nothing more
> required than a "double-click" of the script after the createproject
> and init steps. It should be able to find and set all required django
> and python paths relative to that folder.

+1, seems to be important for 'doze users...

> 5b) Create an alias script to django-admin.py inside the above scripts
> folder. Again, with relative paths in effect, you wouldn't need to set
> the environment variable manually or add it to the command line
> manually...

+1

> (Most of these are not 'architectural' changes, but they sure would be
> nice to have in there when your newbie techie journalists check out
> this new "Django 1.0" thing and start playing with the framework.

HAND,
(c)

--
Carlo C8E Miron, ICQ #26429731
--
Disclaimer:
If I receive a message from you, you are agreeing that:
1. I am by definition, "the intended recipient".
2. All information in the email is mine to do with as I see fit and
make such financial profit, political mileage, or good joke as it
lends itself to. In particular, I may quote it on USENET or the WWW.
3. I may take the contents as representing the views of your company.
4. This overrides any disclaimer or statement of confidentiality that
may be included on your message.