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,
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
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
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
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 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
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 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
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
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
10 matches
Mail list logo
