Tim,
Yes I see. This is great. I agree with your assessments in full.
On 10/31/2014 06:19 PM, Tim Graham wrote:
> Hi Justin,
>
> Thanks for the feedback. Making 1.8 the next LTS was discussed a bit
> internally before I shared the idea and tentative schedule for the 1.8
> release on the thread
Hi Justin,
Thanks for the feedback. Making 1.8 the next LTS was discussed a bit
internally before I shared the idea and tentative schedule for the 1.8
release on the thread "1.8 release planning." The only feedback on that
thread (2 weeks ago) was from Josh Smeaton who supported the details
ou
Tim,
This truly is a stellar report. Thanks so much.
I do have one question about this statement:
> A reminder that we expect Django 1.8 to become the next LTS version of
Django, so if you have a pet bug or feature, now's a great time to get
it fixed!
You characterize this as a "reminder" - I
Hello,
If you've read the djangoproject.com blog, you know that Berker Peksag and
I have been appointed as "Django Fellows" during the three month pilot
program. Part of those duties (which started this week) is to provide a
weekly summary of our activities to this mailing list. That report fol
On Fri, Oct 31, 2014 at 9:46 AM, Andrew Godwin wrote:
> So, bear in mind that you can easily set these defaults yourself in a
> migration with RunSQL if you need them for legacy purposes; that way they'll
> get applied
Absolutely. I effectively have such a system in place at the moment.
But, my
So, bear in mind that you can easily set these defaults yourself in a
migration with RunSQL if you need them for legacy purposes; that way
they'll get applied, we don't need to add more code to Django, and it works
fine for simple plain defaults without the need for a system where Django
tries to w
On Fri, Oct 31, 2014 at 6:48 AM, Shai Berger wrote:
> Peter, you said you're "interested in getting database migrations to support
> setting database-level default values", but you haven't said why; unless
> there's a convincing use-case, I'm going to be -1 on this (per the new rules,
> this is no
Hi Everyone,
I just mentioned in another thread that db-level defaults are particularly
troublesome on Oracle. I didn't want to burden that discussion with the
detais, but having been asked about it on IRC (thanks Josh), here they are.
The problem is caused by a combination of factors:
1) Orac
On Thursday 30 October 2014 23:00:18 Andrew Godwin wrote:
>
> If this does happen, I'd probably want some way to declare what defaults to
> keep. (South actually used to have this with a keep_default option on the
> add_column method but it was kind of unmaintained)
>
IIRC, in the few South relea
My preference for this would be option 3., on the grounds that:
* I'd rule out 1 because of the slight backwards incompatibility (which
can affect people - I remember a deploy script failing because of a
changed exit code for a Mercurial command). In particular, currently
there are other condition
10 matches
Mail list logo
