If I get this correctly, this has an interesting effect:
If Django 1.9 supports API Target Versions 1.7 and 1.8 at its launch, then it
must also support them for its lifetime (dropping them would be the kind of
change we don't introduce in minor versions). 1.7's API would need to be
supported a
On Thursday 12 November 2015 18:22:23 Tim Graham wrote:
> The expected behavior of the {% if %} tag isn't clear to me. How do you
> propose to solve the "bug"? As I noted in the ticket:
>
> We end up checking {% if %} which passes for a
> non-empty string_if_invalid.
It seems pretty obvious to
2015-11-12 17:40 GMT+01:00 Carl Meyer :
> On 11/12/2015 05:48 AM, Patryk Zawadzki wrote:
>> * Setting the target version to a higher value could turn deprecation
>> warnings to exceptions for all features deprecated in the target
>> version and earlier (which could make future-proofing your code
>>
On 11/12/2015 09:22 AM, Tim Graham wrote:
> The expected behavior of the {% if %} tag isn't clear to me. How do you
> propose to solve the "bug"? As I noted in the ticket:
>
> We end up checking {% if %} which passes for a
> non-empty string_if_invalid. I'm not sure we should add special handling
Hi Patryk,
On 11/12/2015 05:48 AM, Patryk Zawadzki wrote:
> I have spent quite a while thinking about this and am still not sure
> what the best approach would be or even if there are enough benefits
> to justify the change.
I think the idea is interesting (and I know it's been at least briefly
d
The expected behavior of the {% if %} tag isn't clear to me. How do you
propose to solve the "bug"? As I noted in the ticket:
We end up checking {% if %} which passes for a
non-empty string_if_invalid. I'm not sure we should add special handling of
RelatedObjectDoesNotExist in the template eng
Hi,
"It would also make it theoretically possible for the latest stable version
to support the
last LTS version from the same code tree".
Have you seen the latest changes to the deprecation policy? We hope we've
done exactly that (having the latest version of Django support code that
was writ
Hello everyone,
I have spent quite a while thinking about this and am still not sure
what the best approach would be or even if there are enough benefits
to justify the change.
If you've ever worked with compiled code, you're probably familiar
with ABI versioning in dynamic libraries. This is som
On 8 Nov 2015, at 08:31, Marc Tamlyn wrote:
> I'm definitely in favour of a format allowing multiple storage back ends
> referred to by name. For larger sites it is not unusual to manage files
> across multiple locations (eg several S3 buckets). The storage param to
> FileField would be allowe
