e, so I'm not
really sure how big of a difference it would have made.
El lunes, 21 de diciembre de 2015, 12:09:31 (UTC-3), Tim Graham escribió:
>
> I'd like to ask for opinions about whether or not deprecations are more
> useful than making small backwards incompatible changes
On Monday 21 December 2015 20:45:26 Carl Meyer wrote:
>
> Obviously the first question is whether the behavior in question is
> documented. If it is, then a deprecation path is definitely required. On
> the other hand, if the current behavior contradicts the documentation,
> then it's a bug and ca
Hi Tim,
On 12/21/2015 08:09 AM, Tim Graham wrote:
> I'd like to ask for opinions about whether or not deprecations are more
> useful than making small backwards incompatible changes when they move
> Django in a direction toward unhiding probable developer error.
>
> An
I'd like to ask for opinions about whether or not deprecations are more
useful than making small backwards incompatible changes when they move
Django in a direction toward unhiding probable developer error.
An example from a past release is the validation of fields in
select_related
On Wednesday, November 20, 2013 5:17:11 PM UTC+2, Shai Berger wrote:
>
> Hi,
>
> On Saturday 16 November 2013 21:02:00 Anssi Kääriäinen wrote:
> > Any feedback for pre/post_update idea?
> >
> As Loic said, the signals sound like they can be useful in a variety of
> situations. A couple of note
Hi,
On Saturday 16 November 2013 21:02:00 Anssi Kääriäinen wrote:
> Any feedback for pre/post_update idea?
>
As Loic said, the signals sound like they can be useful in a variety of
situations. A couple of notes, though:
> pre_update listeners get a queryset that isn't executed.
The "query" par
On Nov 17, 2013, at 2:02 AM, Anssi Kääriäinen wrote:
> - Reverse ForeignKey .remove() will not use .save() - it will use .update()
> - so no model save signals, and overridden model.save() is missed, too.
+1 on the pre/post_update signals as they can be useful for a variety of
purposes.
Al
On Thursday, October 24, 2013 11:40:37 PM UTC+3, Anssi Kääriäinen wrote:
> Here is the full list of changes that potential for breaking user code:
> - If related object's default manager has default filtering, then
> .remove() and .clear() will not clear those items that are filtered out.
> -
Somewhat long post ahead - jump to the list in the end of post to see the
backwards incompatible changes.
Ticket #21169 deals with a bunch of different related manager improvements.
Some are bug fixes, some are there to make related manager methods work
consistently and finally the ticket&#
d some.
Perhaps we could have two sections on that page — all release notes,
and upgrading notes. Or, next to 'final' releases there could be an
additional link to the 'backwards incompatible changes' section, along
with some notes at the top explaining the page.
Luke
-
#x27; section on [1]
>> has a link to 'Backwards-incompatible changes' [2], which contains
>> pre-1.0 changes only, and a notice at the top saying you don't need to
>> read it if your code is post 1.0. Also, the archive of release notes
>> [3] incorrectly says that B
On Sat, Nov 14, 2009 at 8:55 AM, Luke Plant wrote:
> Hi all,
>
> The online docs can easily give the impression that we have perfect
> compatibility with Django 1.0 — the 'Django over time' section on [1]
> has a link to 'Backwards-incompatible changes' [2], wh
Hi all,
The online docs can easily give the impression that we have perfect
compatibility with Django 1.0 — the 'Django over time' section on [1]
has a link to 'Backwards-incompatible changes' [2], which contains
pre-1.0 changes only, and a notice at the top saying you do
On 4/8/07, Simon G. <[EMAIL PROTECTED]> wrote:
> I believe that the plan for 1.1 is to rewrite Django in Lisp or
> Haskell. Or is Scheme the cool one now?
Erlang!
Jacob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Group
I believe that the plan for 1.1 is to rewrite Django in Lisp or
Haskell. Or is Scheme the cool one now?
j/k
--Simon
On Apr 8, 4:34 am, "Noah" <[EMAIL PROTECTED]> wrote:
> I'm worried about a trend I've seen before in other frameworks etc.
> They start off easier to use and over time get more an
On 4/7/07, Noah <[EMAIL PROTECTED]> wrote:
> I'm worried about a trend I've seen before in other frameworks etc.
> They start off easier to use and over time get more and more
> generalized and then become so general and so academically correct
> that there is no point in using them because they'r
On 4/7/07, Noah <[EMAIL PROTECTED]> wrote:
>
> I'm worried about a trend I've seen before in other frameworks etc.
> They start off easier to use and over time get more and more
> generalized and then become so general and so academically correct
> that there is no point in using them because they
I'm worried about a trend I've seen before in other frameworks etc.
They start off easier to use and over time get more and more
generalized and then become so general and so academically correct
that there is no point in using them because they're just as general
as if you had to write all your o
On Fri, 2007-04-06 at 12:39 -0700, Jonas Maurus wrote:
[...]
> So I'd say: make the next release painful and then stop until 1.1.
> Make all the changes now, including full unicodization and newforms-
> admin and if it's still on the map the "Admin"-class-removal that was
> being discussed a while
On Apr 6, 2:16 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> Hi all,
>
> A few backwards incompatible changes have been raised on the list in
> the last week or so:
>
> - Removing auto_add_now and auto_add
> - Removing LazyDate
> - Renaming loc
On 4/6/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> I like Jeremy's idea of posting to django-users and django-announce,
> saying the development version will be a bit tumultuous for the
> immediate future. I'll send out that announcement.
>
Would it also be worth updating the FAQ?
http://www
On 4/6/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> This raises the question - do we have any particular timeline or
> strategy for making these changes? Is there any particular reason to
> hold off on making these changes, or should we just jump in a make
> them, along with making a note
On 4/6/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
...
> I would suggest we post once to django-users reminding people to look at
> the backwards-incompatible changes page *first* when they see a problem
> arise and to stick with 0.96 is they value stability. Then we can sta
On Fri, 2007-04-06 at 20:16 +0800, Russell Keith-Magee wrote:
> Hi all,
>
> A few backwards incompatible changes have been raised on the list in
> the last week or so:
>
> - Removing auto_add_now and auto_add
> - Removing LazyDate
> - Renaming localflavour.usa to
Hi all,
A few backwards incompatible changes have been raised on the list in
the last week or so:
- Removing auto_add_now and auto_add
- Removing LazyDate
- Renaming localflavour.usa to localflavor.us
This raises the question - do we have any particular timeline or
strategy for making these
25 matches
Mail list logo
