On Wed, Dec 12, 2012 at 3:56 PM, Michael Elsdörfer wrote:
> $ pip install django==1.1
If you mean "The most recent point release in the 1.1 family", then
that is "Django>1.1,<1.2"*.
If you mean 1.1.1, then that is "Django==1.1.1"
Cheers
Tom
* If you are using pypi, then "Django<1.2" will do th
The point is that you should be using 1.1.4, the latest release in the 1.1
line, and not 1.1.
Jacob
On Sun, Dec 16, 2012 at 12:38 PM, donarb wrote:
>
>
> On Saturday, December 15, 2012 3:54:10 AM UTC-8, Florian Apolloner wrote:
>>
>> I am strongly against showing non-supported versions on PYPI
On Saturday, December 15, 2012 3:54:10 AM UTC-8, Florian Apolloner wrote:
>
> I am strongly against showing non-supported versions on PYPI, I also don't
> see why you'd need 1.1 for CI tests if you don't use it (an nobody should)
>
I disagree. I have a client who is currently running a site wit
On Friday, December 14, 2012 9:01:27 PM UTC+1, Michael Elsdörfer wrote:
>
> I'm only using Django 1.1 as part of CI tests, and they have started
> failing recently because of this, so I'd be happy to see it fixed.
>
I am strongly against showing non-supported versions on PYPI, I also don't
see w
I'm only using Django 1.1 as part of CI tests, and they have started
failing recently because of this, so I'd be happy to see it fixed.
--
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@g
The exact versions of Django available on Pypi are here:
http://pypi.python.org/simple/Django/
Nobody recommends installing this old version of Django for production, but
you can install 1.1.4 like so:
pip install django==1.1.4
On Wednesday, December 12, 2012 11:37:58 AM UTC-8, Will Van Wazer wr
Despite not being listed on PyPi, installing Django 1.1 works if you do
this:
pip install 'Django<1.2'
---
Will Van Wazer
The Washington Post
(202) 334-9967 (w)
(703) 785-1448 (c)
On Wed, Dec 12, 2012 at 11:12 AM, Jacob Kaplan-Moss wrote:
> I'm not sure why it's hidden on PyPI, but in t
I'm not sure why it's hidden on PyPI, but in the meantime you can get it
from https://www.djangoproject.com/download/.
I should point out that 1.1 is woefully out of date and no longer receives
security updates. There are probably security vulnerabilities and certainly
bugs; you should really upgr
Awesome work guys, congrats. Been running off trunk in production for a
while now, looking forward to see what 1.2 brings :)
Mat
On Wed, Jul 22, 2009 at 8:16 AM, Michael Kerrin wrote:
> Hi,
>
> Thanks for the update, I am looking forward to the release there is a lot
> of good stuff in there.
>
Go Django! Thanks to everybody and specially developers!
Dhruv Adhia
http://thirdimension.com
On Tue, Jul 21, 2009 at 7:35 PM, James Bennett wrote:
>
> Hi folks! Tonight we've pushed out the Django 1.1 release candidate,
> which is hopefully the last stepping-stone to the final 1.1 release.
> I
Hi,
Thanks for the update, I am looking forward to the release there is a lot of
good stuff in there.
Thanks again,
Michael
2009/7/21 Russell Keith-Magee
>
> On Tue, Jul 21, 2009 at 5:02 PM, Michael Kerrin
> wrote:
> > Hi All,
> >
> > I am working on a project that is currently running Django
On Tue, Jul 21, 2009 at 5:02 PM, Michael Kerrin wrote:
> Hi All,
>
> I am working on a project that is currently running Django 1.1Beta from
> March 23rd.
> I am enquiring about the road map for the Django 1.1 release as I have not
> seen much talk on the mailing list (I don't pay much attention t
As I understand it; All of the 'real' tickets are fixed.
http://twitter.com/freakboy3742/status/2671770783
People are adding new tickets and assigning them to 1.1, because they can,
but these are generally being rejected or move to 1.2 I think. I'm not sure
when we will see 1.1 out the door but I
2009/5/7 Jacob Kaplan-Moss
>
> Now, we can't ship with anything that actually causes data loss,
>
i know you asked for reducing the number of tickets for 1.1, but i think one
should actually be added:
http://code.djangoproject.com/ticket/6191
this does not only cause data loss, but is causes d
On Thu, May 7, 2009 at 8:34 AM, Jacob Kaplan-Moss
wrote:
> Ugh, I really hate not being able to just assign files to fields. It
> just feels hacky and wrong to call instance.file_field.save(). It'll
> also break a bunch of code folks have written over the last few
> months. I know, no backwards-c
On Thu, May 7, 2009 at 12:43 PM, Jacob Kaplan-Moss wrote:
> I'm hard at work punting tickets out of the 1.1 milestone. It's tough
> to do, but this is what time-based releases mean: sometimes you have
> to ship with known issues.
Update: I've pushed/closed all the issues I plan to. We're now at
On Thu, May 7, 2009 at 1:09 PM, Marty Alchin wrote:
> While I still think that's a valuable feature, and will likely be
> required in order to complete Honza's model validation work for GSOC,
> it's really a new feature that has so far caused far more bugs than
> it's worth. I'd like to recommend
On Thu, May 7, 2009 at 6:43 AM, Jacob Kaplan-Moss wrote:
> Once this is done we'll be down to blockers for 1.1; many of us at the
> sprint are focusing on these. More help will be appreciated!
I just wanted to add a note here that may have some impact on which
tickets get punted vs. fixed in 1.1
Thanks Alex/George
I second the point that a buggy release is what we would not want. As
one of the third party module developer, I just wanted to keep myself
updated about it. Thus, was just curious to know if there is any
strict schedule already been followed and not updated on the website.
Tha
On 5/5/2009 9:20 PM, Tarun Pasrija wrote:
> I recently checked the schedule for Django 1.1 final release and the
> website says April 13th.
>
> http://code.djangoproject.com/wiki/Version1.1Roadmap.
>
> Are there any updates about the change in schedule and when is the
> final going to be release
On Wed, May 6, 2009 at 6:20 AM, Tarun Pasrija wrote:
>
> Hi All
>
> I recently checked the schedule for Django 1.1 final release and the
> website says April 13th.
>
> http://code.djangoproject.com/wiki/Version1.1Roadmap.
>
> Are there any updates about the change in schedule and when is the
> fin
James Bennett wrote:
> if you'd like to try out the new features or go bug-hunting
> in a safe environment, feel free to take it for a sping.
Django-1.1-alpha-1.tar.gz reports:
^^^
$ python -c "import django; print django.VERSION"
(1, 0, 2, 'final', 0)
Deliberate?
Regards,
Chris Lamb wrote:
> Django-1.1-alpha-1.tar.gz reports:
>^^^
>
> $ python -c "import django; print django.VERSION"
> (1, 0, 2, 'final', 0)
>
> Deliberate?
Ignore this; PEBCAK.
Regards,
--
Chris Lamb, UK ch...@chris-lamb.co.uk
On Nov 17, 10:31 am, Jannis Leidel <[EMAIL PROTECTED]> wrote:
>
> Importing in the settings.py is effectively not required by any other
> part of Django.
Is importing in settings.py regarded generally as bad practice? If so,
I wasn't aware of this.
> What do you mean by "which you don't contro
On Nov 17, 11:20 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
>
> The InstalledAppsRevision wiki page. That was produced after the PyCon
> sprint. Since that involved a bunch of people, a number of them
> maintainers, I tend to view it as fairly canonical as to what is wanted
> in the feat
On Mon, 2008-11-17 at 02:24 -0800, Vinay Sajip wrote:
>
>
> On Nov 17, 1:13 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
> > My -1 is because of basically the same thing Jannis has pointed out (and
> > as I mentioned in my comment). There's a big ticket with various
> > proposals and at
>> Indeed, my idea though is to dodge imports in settings.py and just
>> use
>> dotted module names.
>
> I'm not sure why importing in settings.py is such a bad thing. Putting
> in dotted module names just moves the importing to somewhere else
> (which you don't control) and seems more 'magical'
On Nov 17, 1:13 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> My -1 is because of basically the same thing Jannis has pointed out (and
> as I mentioned in my comment). There's a big ticket with various
> proposals and at some point last year Adrian mentioned he had another
> idea and that
On Nov 17, 12:50 am, Jannis Leidel <[EMAIL PROTECTED]> wrote:
>
> The two -1 from core devs veto the feature for the next version, not
> the whole feature. We can go on discussing it here. I still hope they
> chime in though :)
>
I hope so too.
>
> Indeed, my idea though is to dodge imports in
On Mon, 2008-11-17 at 01:50 +0100, Jannis Leidel wrote:
> >>> If the basic premise of an app class - instances of which can
> >>> live in
> >>> settings.INSTALLED_APPS - is acceptable (and, of course, this means
> >>> instances of subclasses of app can live in settings.INSTALLED_APPS
> >>> too
>>> If the basic premise of an app class - instances of which can
>>> live in
>>> settings.INSTALLED_APPS - is acceptable (and, of course, this means
>>> instances of subclasses of app can live in settings.INSTALLED_APPS
>>> too) then the precise location of an implementation (e.g.
>>> django.c
On Nov 16, 7:48 pm, Jannis Leidel <[EMAIL PROTECTED]> wrote:
> >>> Well, what are those features you wanted, explicitly?
>
> There was a case for multiple instances of apps when it was discussed
> at the Pycon sprint and I just forgot it.
>
Ok - I'm not saying there's no case for it, just that
>>> Well, what are those features you wanted, explicitly?
>>
>> Mostly what has been written down
>> athttp://code.djangoproject.com/wiki/InstalledAppsRevision
>
> Thank you for your response. If you mean
>
>* Allow change of name of third-party app
>* Allow change of db_prefix of third-p
On Nov 15, 7:19 pm, Jannis Leidel <[EMAIL PROTECTED]> wrote:
> Thanks for bringing this topic up for discussion.
>
> > jezdez says: "As Jacob said, that's such a pain. I tried and wasn't
> > able to implement even part of the wanted features. The app cache
> > needs a thourough look. But I don't
On Nov 15, 6:57 pm, David Cramer <[EMAIL PROTECTED]> wrote:
> I personally was a 0 on this one. Let me explain why. I want Django to
> be a strong platform for developers, like myself, who really want the
> opportunity to have power in the framework, as well as features. As of
> lately I have be
Thanks for bringing this topic up for discussion.
> jezdez says: "As Jacob said, that's such a pain. I tried and wasn't
> able to implement even part of the wanted features. The app cache
> needs a thourough look. But I don't see installing apps multiple times
> as a favored feature. I will happi
I personally was a 0 on this one. Let me explain why. I want Django to
be a strong platform for developers, like myself, who really want the
opportunity to have power in the framework, as well as features. As of
lately I have been using Rails for a project, and to be quite honest,
the maturity and
I haven't looked at the patch yet, but I'd really like to be able to
change an app's name (and with it the names of the database tables),
which I thought was something that this proposal would include. So
fwiw, I personally would like to see it in 1.1.
Michael
--~--~-~--~~
On Nov 15, 12:27 pm, Vinay Sajip <[EMAIL PROTECTED]> wrote:
> Re. the recent post by Jacob Kaplan-Moss on Django 1.1 features and
> votes:
>
> ORM-23 gets a +1 from me. Jacob has given it a -0 and a comment "A
> huge can of worms. Some really awesome benefits come out of this, but
> so far every
39 matches
Mail list logo
