Re: 1.9 release planning

[Anssi Kääriäinen]

+1 to Collin's release schedule.

This schedule should make it extremely easy to support "develop using
latest release, maintain using latest LTS". With the above schedule if
you started with 1.8 you are already on LTS. If you start with 1.9,
you should have an easy upgrade path all the way till 2.1 which is
LTS. Also upgrading from 1.8 to 2.1 should be easy enough if you
didn't use any deprecated features when running on 1.8.

 - Anssi

On Thu, Jun 11, 2015 at 12:06 AM, Tim Graham  wrote:
> Yep, I think Collin's schedule is it. I'm happy with that option and 3rd
> party apps shouldn't need to add any compatibility shims to support 2
> releases -- they just need to ensure they aren't using any deprecated APIs.
>
>
> On Wednesday, June 10, 2015 at 3:48:39 PM UTC-4, Collin Anderson wrote:
>>
>> Hi Tim,
>>
>> What I mean is we could still make it easy to support both LTS releases,
>> even if we drop features deprecated in 1.8 before the next LTS according to
>> the normal release schedule. Right? Because apps wouldn't need to use those
>> deprecated features to support both 1.8 and 2.1. We could drop them in 2.0
>> like normal?
>>
>> I'm trying to lessen the increased maintenance burden of Loic's proposal
>> while still making it possible to easily support both LTS releases.
>>
>> > For "maintenance costs" I am not worried about supported deprecated APIs
>> > in old releases, only how long they stay around in master as that could be 
>> > a
>> > barrier to innovation.
>> Right, so the cost would be an extra 8 months before removing features
>> deprecated in 1.9 from master.
>>
>> Thanks,
>> Collin
>>
>> On Wednesday, June 10, 2015 at 2:09:13 PM UTC-4, Tim Graham wrote:
>>>
>>> Collin, I'm not following your reasoning about why dropping features
>>> deprecated in one LTS (e.g. 1.8) in the next LTS (e.g. 2.1; I think you made
>>> a typo in your timeline putting it next to 2.0?) will make it possible to
>>> easily support both LTS releases? That's the purpose of Loic's proposal I
>>> believe.
>>>
>>> For "maintenance costs" I am not worried about supported deprecated APIs
>>> in old releases, only how long they stay around in master as that could be a
>>> barrier to innovation.
>>>
>>> On Wednesday, June 10, 2015 at 1:54:53 PM UTC-4, Collin Anderson wrote:

 On Friday, May 8, 2015 at 12:12:37 PM UTC-4, Carl Meyer wrote:
>
> And there is a significant added maintenance cost to my proposal
> compared to yours. Dropping deprecated APIs in the release after an LTS
> means we still have to support those APIs for three more years
> (possibly
> for four or five years after they were first deprecated). Dropping them
> _in_ the LTS release shortens that window drastically.


 If we release every 8 months, that means we normally support deprecated
 features for 2 years. If we maintained LTS compatibility, then, yes, that
 would mean "supporting" the APIs for more than 5 years after deprecation.
 But to be clear, most of that time it's only security support for those
 APIs, and the APIs are long gone from master. Right?

 Thanks,
 Collin


 On Wednesday, June 10, 2015 at 1:37:30 PM UTC-4, Collin Anderson wrote:
>
> Hi All,
>
> Here are some thoughts in reply to some of the comments in the
> django-compat thread. I don't stick to the LTSs myself, but I've helped
> maintain apps that have 1.4 compatibility.
>
> On Tuesday, June 9, 2015 at 7:05:45 PM UTC-4, Loïc Bistuer wrote:
>>
>> 1.8 (LTS): No features dropped.
>> 1.9: Dropped features deprecated in 1.4, 1.5, 1.6, 1.7
>> 2.0: No features dropped.
>> 2.1 (LTS): No features dropped.
>> 2.2: Dropped features deprecated in 1.8, 1.9, 2.0
>
>
> I'd propose something slightly different, that's very close to our
> current deprecation timeline:
> 1.8 (LTS): No features dropped.
> 1.9: Dropped features deprecated in 1.5, 1.6, 1.7
> 2.0: Dropped features deprecated in 1.8
> 2.1 (LTS): No features dropped.
> 2.2: Dropped features deprecated in 1.9, 2.0
> 2.3: Dropped features deprecated in 2.1
>
> Seems to me features deprecated in an LTS are fair game to disappear in
> the next LTS. This allows us to remove "dotted paths in reverse() and 
> url()"
> because that's deprecated in 1.8.
>
> If we can guarantee compatibility between LTSs, I think that would be a
> huge win, at the cost of extending the removal of some deprecated features
> by one release (8 months).
>
> Collin
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this 

Re: Template-based widget rendering

[Preston Timmons]

Hi Carl,

Thanks for the feedback. I agree with your suggestions. I didn't think about
running a check for a combination of INSTALLED_APPS and a loader with
APP_DIRS. That would be sufficient for customizing loading.

I'll update and convert this to a PR.

Preston

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7e2e0274-aea5-42c0-92ba-f4b54346dd6c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: how to deal with inspect.getargspec() deprecation?

[Tim Graham]

The APIs are rather different. I will keep working on the conversions 
(we'll need them no matter which option we pick), but here's a flavor: 
https://github.com/django/django/pull/4846

On Wednesday, June 10, 2015 at 3:50:52 PM UTC-4, Carl Meyer wrote:
>
> On 06/10/2015 01:48 PM, Berker Peksağ wrote: 
> > On Wed, Jun 10, 2015 at 9:49 PM, Tim Graham  > wrote: 
> >> inspect.getargspec() was deprecated in Python 3.0 and will be removed 
> in 3.6 
> >> (ETA late 2016). It started throwing a deprecation warning in Python 
> 3.5 
> >> which causes some test failures when we check the number of deprecation 
> >> warnings so I'd like to deal with it now and avoid introducing more 
> usages. 
> >> 
> >> Its replacement is inspect.signature() which is in all the versions of 
> >> Python 3 we support, but not 2.7. Options I see: 
> >> 1. Add a dependency for the funcsigs backport [1] (only needed on 
> Python 2) 
> >> 2. Vendor funcsigs in django.utils (about 1k LOC) (this has been the 
> >> historical approach) 
> >> 3. Write different code for Python 2 & 3 
> > 
> > funcsigs doesn't look like an up-to-date backport and we've fixed many 
> > bugs in inspect.signature() in recent releases. It might be safer to 
> > go with 3 (instead of adding an unmaintained dependency). 
>
> If that's true, then we should write our own backport that covers the 
> cases we need (and consider contributing it to six, as Marc suggested). 
> We shouldn't rewrite the compatibility code every place we need an 
> argument signature (which is how I interpret option 3). 
>
> Calr 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8479b68f-0abe-44bd-9729-abfcca40288f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Template-based widget rendering

[Carl Meyer]

Hi Preston,

On 06/10/2015 11:46 AM, Preston Timmons wrote:
> I've been working through solutions for #15667 -- template based widget
> rendering. This is a problem that was close to a solution at one time, but
> stalled out due to performance concerns and difficulties with defining a
> workable API to create configurable template loaders.
> 
> Now that Jinja2 is supported, performance isn't as much a concern. So,
> I'd like to tackle the API portion of this.

Thanks for picking this up again!

> This problem has two sides:
> 
> 1) Converting individual widgets to be rendered with templates.
> 2) Deciding how to instantiate a user-customizable template engine.
> 
> The first is easy to accomplish, but the second isn't. I've written a
> proposal for the second problem available here:
> 
> https://gist.github.com/prestontimmons/24a2a835bea590afb70b

This proposal looks excellent. A few comments:

1) I think the new `renderer` argument to `Widget.render()` should be
kept optional, and BoundField should have a fallback to not pass it in
if not accepted, in order to avoid requiring immediate
backwards-incompatible updates to custom widgets' render() methods. The
Widget.render() method's signature is documented, so it is covered by
the backwards-compatibility policy. The BoundField calling fallback can
have a deprecation path; keeping the renderer arg optional forever (with
fallback to default renderer from settings) doesn't seem like a terrible
idea.

2) I don't think that looking up the magic name 'forms' in `TEMPLATES`
is a good idea for overriding the forms template loader. I think it
would be better to just require using a custom renderer (which can be a
simple subclass of the built-in TemplateRenderer) for that case.

3) Regarding the template-precedence conundrum you mentioned: IMO the
best end-result here is to simply add 'django.forms' to
`INSTALLED_APPS`. This provides full flexibility (you can order
`INSTALLED_APPS` however you like to override with templates from a
different app, or of course override with templates in `DIRS`) without
requiring any new concepts. So then the question is just a
backwards-compatibility path for getting 'django.forms' into
`INSTALLED_APPS`. Here's what I'd propose:

The default `TemplateRenderer` has an `engine` cached-property, with the
following behavior:

a) If 'django.forms' is in `INSTALLED_APPS` and there is at least one
configured template engine with `APP_DIRS: True`, return `None`.

b) Otherwise, fallback to instantiating and returning a simple Jinja2
backend (similar to the `default_backend` in your gist, but I think even
more stripped down, with `APP_DIRS: False`). Raise a (pending)
deprecation warning.

If `TemplateRenderer.engine` is `None`, then `TemplateRenderer.render`
would use `django.template.loader.get_template` (thus using the same
engine fallback strategy as normal template rendering from a view).

Document in the form-rendering docs (and in the release upgrade notes,
which are linked to by the above deprecation warning) that if you want
to override the default form widget templates, you need to include
'django.forms' in `INSTALLED_APPS` and make sure you have at least one
template engine with `APP_DIRS: True`. Overriding widget templates is a
new feature, so it's OK if it requires explicit opt-in.

Once the deprecation warning runs its course, the default
`TemplateRenderer.engine` property would simply return `None` in all
cases (unless we add an `engine_name` class attr; see below), thus
deferring to normal template rendering, and there would be no
automatically-generated special template engine for forms.

I think this provides a full backwards-compatible path for the simplest
case, while still preserving all the flexibility you could want. If you
don't want the built-in templates at all, and want to provide all your
own, you don't need `APP_DIRS: True` or 'django.forms' in
`INSTALLED_APPS`. If you want to only use a specific template engine for
form widgets, you can subclass `TemplateRenderer` and override the
`engine` property to return your engine (which could be instantiated
right there in the renderer, or could be from the `TEMPLATES` setting
and fetched in the renderer using `get_engine`).

To make the latter customization even simpler, we could add an
`engine_name` attribute on `TemplateRenderer`, defaulting to `None`, but
if set to anything other than `None`, the `engine` property would call
`get_engine` with that name. Then the subclass only has to define the
`engine_name` attribute to enforce use of a specific engine.

Or if that type of customization turns out to be very common, we could
even go one step further and add a `FORM_RENDERER_TEMPLATE_ENGINE`
setting which can be set to a template engine name, to avoid needing to
subclass `TemplateRenderer` at all.

(My feeling is we should probably do the `TemplateRenderer.engine_name`
thing, but not the setting.)

> In addition, a WIP branch is available here:
> 
> 

Re: 1.9 release planning

[Tim Graham]

Yep, I think Collin's schedule is it. I'm happy with that option and 3rd 
party apps shouldn't need to add any compatibility shims to support 2 
releases -- they just need to ensure they aren't using any deprecated APIs.

On Wednesday, June 10, 2015 at 3:48:39 PM UTC-4, Collin Anderson wrote:
>
> Hi Tim,
>
> What I mean is we could still make it easy to support both LTS releases, 
> even if we drop features deprecated in 1.8 before the next LTS according to 
> the normal release schedule. Right? Because apps wouldn't need to use those 
> deprecated features to support both 1.8 and 2.1. We could drop them in 2.0 
> like normal?
>
> I'm trying to lessen the increased maintenance burden of Loic's proposal 
> while still making it possible to easily support both LTS releases.
>
> > For "maintenance costs" I am not worried about supported deprecated APIs 
> in old releases, only how long they stay around in master as that could be 
> a barrier to innovation.
> Right, so the cost would be an extra 8 months before removing features 
> deprecated in 1.9 from master.
>
> Thanks,
> Collin
>
> On Wednesday, June 10, 2015 at 2:09:13 PM UTC-4, Tim Graham wrote:
>>
>> Collin, I'm not following your reasoning about why dropping features 
>> deprecated in one LTS (e.g. 1.8) in the next LTS (e.g. 2.1; I think you 
>> made a typo in your timeline putting it next to 2.0?) will make it possible 
>> to easily support both LTS releases? That's the purpose of Loic's proposal 
>> I believe.
>>
>> For "maintenance costs" I am not worried about supported deprecated APIs 
>> in old releases, only how long they stay around in master as that could be 
>> a barrier to innovation.
>>
>> On Wednesday, June 10, 2015 at 1:54:53 PM UTC-4, Collin Anderson wrote:
>>>
>>> On Friday, May 8, 2015 at 12:12:37 PM UTC-4, Carl Meyer wrote:

 And there is a significant added maintenance cost to my proposal 
 compared to yours. Dropping deprecated APIs in the release after an LTS 
 means we still have to support those APIs for three more years 
 (possibly 
 for four or five years after they were first deprecated). Dropping them 
 _in_ the LTS release shortens that window drastically.
>>>
>>>
>>> If we release every 8 months, that means we normally support deprecated 
>>> features for 2 years. If we maintained LTS compatibility, then, yes, that 
>>> would mean "supporting" the APIs for more than 5 years after deprecation. 
>>> But to be clear, most of that time it's only security support for those 
>>> APIs, and the APIs are long gone from master. Right?
>>>
>>> Thanks,
>>> Collin
>>>
>>>
>>> On Wednesday, June 10, 2015 at 1:37:30 PM UTC-4, Collin Anderson wrote:

 Hi All,

 Here are some thoughts in reply to some of the comments in the 
 django-compat thread. I don't stick to the LTSs myself, but I've helped 
 maintain apps that have 1.4 compatibility.

 On Tuesday, June 9, 2015 at 7:05:45 PM UTC-4, Loïc Bistuer wrote:
>
> 1.8 (LTS): No features dropped. 
> 1.9: Dropped features deprecated in 1.4, 1.5, 1.6, 1.7 
> 2.0: No features dropped. 
> 2.1 (LTS): No features dropped. 
> 2.2: Dropped features deprecated in 1.8, 1.9, 2.0 
>

 I'd propose something slightly different, that's very close to our 
 current deprecation timeline:
 1.8 (LTS): No features dropped.
 1.9: Dropped features deprecated in 1.5, 1.6, 1.7
 2.0: Dropped features deprecated in 1.8
 2.1 (LTS): No features dropped. 
 2.2: Dropped features deprecated in 1.9, 2.0
 2.3: Dropped features deprecated in 2.1

 Seems to me features deprecated in an LTS are fair game to disappear in 
 the next LTS. This allows us to remove "dotted paths in reverse() and 
 url()" because that's deprecated in 1.8.

 If we can guarantee compatibility between LTSs, I think that would be a 
 huge win, at the cost of extending the removal of some deprecated features 
 by one release (8 months). 

 Collin



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bbc5256e-f5e9-445d-9d35-601a55568b30%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Minor Feature Request: Unconfigured Allowed_Hosts Setting Should Raise ImproperlyConfigured Error

[Robert Roskam]

I'll give it a shot. First day here in the group, so wasn't sure of the 
procedures.

On Wednesday, June 10, 2015 at 2:58:25 PM UTC-4, Tim Graham wrote:
>
> I forgot about the existing settings checks in django.conf__init__.py. 
> That seems like a reasonable place.
>
> Robert do you want to try to write a patch and/or open a ticket?
>
> On Wednesday, June 10, 2015 at 2:38:31 PM UTC-4, Carl Meyer wrote:
>>
>> On 06/10/2015 11:55 AM, Tim Graham wrote: 
>> > We added such a check in runserver [1]. 
>>
>> Unfortunately, this doesn't help for the (likely) most common case of 
>> "local dev with runserver and DEBUG=True, deployment with another server 
>> and DEBUG=False". 
>>
>> > For other servers it seems less 
>> > clear to me where that check would go -- in the WSGI handler? In 
>> > django.setup()? 
>>
>> I was thinking django.setup() or directly in django.conf.settings. 
>>
>> > (obviously, there is no need for ALLOWED_HOSTS if you 
>> > are using Django outside a webserver context, so the check could be 
>> > annoying if it's there). 
>>
>> Yes, this is true. I guess we have to weigh the debugging issues caused 
>> by not having such a check against the (rare?) case of someone running 
>> Django in a non-request-serving capacity with a different settings file 
>> from the one they use to serve requests. (It's that latter clause that 
>> makes it seem a rare case to me - normally when you run e.g. Celery or 
>> some other type of worker process, you'd want to run it with exactly the 
>> same settings as your request-serving processes, in order to avoid other 
>> inconsistencies causing problems.) 
>>
>> And the workaround for the annoying case would be simple - just go ahead 
>> and configure ALLOWED_HOSTS to something non-empty, even though you 
>> technically don't need it. 
>>
>> Carl 
>>
>> > [1] https://code.djangoproject.com/ticket/19875 
>> > 
>> > On Wednesday, June 10, 2015 at 1:40:11 PM UTC-4, Carl Meyer wrote: 
>> > 
>> > On 06/10/2015 09:55 AM, Robert Roskam wrote: 
>> > > I realize this is a simple thing, but I'm sure this will save 
>> some 
>> > > people time. 
>> > > 
>> > > Since Allowed_Hosts is a required setting, when debug mode is 
>> off, it 
>> > > should raise an appropriate ImproperlyConfigured error. 
>> > > 
>> > > I'm sure there's some broader discussion surrounding which 
>> settings 
>> > > should have this and why, but I haven't been able to find it. 
>> > 
>> > This makes sense - a configuration with DEBUG=False and empty 
>> > ALLOWED_HOSTS can't possibly work, so why should we even allow it 
>> to 
>> > start up? Can anyone else recall a reason why we didn't do this? 
>> > 
>> > Carl 
>> > 
>> > -
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fa0243d0-73a3-4040-a34a-baad75bc67bf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Form assets and static file storage

[Carl Meyer]

On 06/10/2015 07:52 AM, Tim Graham wrote:
> The problem has come up before:
> https://code.djangoproject.com/ticket/18455
> 
> but there is some question about whether the design of the Media class
> is something we should try to continue building on:
> https://code.djangoproject.com/ticket/22298
> 
> The suggestion to have the built-in static tag work like admin_static
> does seem like a practical one. The question is whether practicality
> beats purity (keeping contrib dependencies, albeit a conditional one in
> this case, out of core) in this case. I'd say yes, unless there's a
> suitable alternate proposal to address the problem.

It seems like there's some confusion here between form Media and the
'static' template tag; the two do similar things, but are separate. This
report, and #18455, are about form Media, which means having
staticfiles' "static" tag in core builtin tags wouldn't even help. The
problematic code is in Media.absolute_path() method, in
django/forms/widgets.py; template tags are not involved.

I think Jannis' suggestion in #18455 (that there should be a
staticfiles-specific subclass of Media that uses the storage URL) is the
right one, presuming we even want to continue recommending the Media
approach at all. The questions raised about that in #22298 are good
ones. Personally I don't ever use Media, due to the performance effects
of loading lots of little JS files. This gets into the question of
Django's support for "front-end components" that was recently discussed
in another thread.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5578983E.2080602%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: how to deal with inspect.getargspec() deprecation?

[Berker Peksağ]

On Wed, Jun 10, 2015 at 9:49 PM, Tim Graham  wrote:
> inspect.getargspec() was deprecated in Python 3.0 and will be removed in 3.6
> (ETA late 2016). It started throwing a deprecation warning in Python 3.5
> which causes some test failures when we check the number of deprecation
> warnings so I'd like to deal with it now and avoid introducing more usages.
>
> Its replacement is inspect.signature() which is in all the versions of
> Python 3 we support, but not 2.7. Options I see:
> 1. Add a dependency for the funcsigs backport [1] (only needed on Python 2)
> 2. Vendor funcsigs in django.utils (about 1k LOC) (this has been the
> historical approach)
> 3. Write different code for Python 2 & 3

funcsigs doesn't look like an up-to-date backport and we've fixed many
bugs in inspect.signature() in recent releases. It might be safer to
go with 3 (instead of adding an unmaintained dependency).

--Berker

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAF4280%2BzmENf-_Zdaeno5676Srr3%2B7V7mPRWXPA2KVaLqzy4Gw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: how to deal with inspect.getargspec() deprecation?

[Carl Meyer]

On 06/10/2015 01:48 PM, Berker Peksağ wrote:
> On Wed, Jun 10, 2015 at 9:49 PM, Tim Graham  wrote:
>> inspect.getargspec() was deprecated in Python 3.0 and will be removed in 3.6
>> (ETA late 2016). It started throwing a deprecation warning in Python 3.5
>> which causes some test failures when we check the number of deprecation
>> warnings so I'd like to deal with it now and avoid introducing more usages.
>>
>> Its replacement is inspect.signature() which is in all the versions of
>> Python 3 we support, but not 2.7. Options I see:
>> 1. Add a dependency for the funcsigs backport [1] (only needed on Python 2)
>> 2. Vendor funcsigs in django.utils (about 1k LOC) (this has been the
>> historical approach)
>> 3. Write different code for Python 2 & 3
> 
> funcsigs doesn't look like an up-to-date backport and we've fixed many
> bugs in inspect.signature() in recent releases. It might be safer to
> go with 3 (instead of adding an unmaintained dependency).

If that's true, then we should write our own backport that covers the
cases we need (and consider contributing it to six, as Marc suggested).
We shouldn't rewrite the compatibility code every place we need an
argument signature (which is how I interpret option 3).

Calr

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5578950F.2060606%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: 1.9 release planning

[Collin Anderson]

Hi Tim,

What I mean is we could still make it easy to support both LTS releases, 
even if we drop features deprecated in 1.8 before the next LTS according to 
the normal release schedule. Right? Because apps wouldn't need to use those 
deprecated features to support both 1.8 and 2.1. We could drop them in 2.0 
like normal?

I'm trying to lessen the increased maintenance burden of Loic's proposal 
while still making it possible to easily support both LTS releases.

> For "maintenance costs" I am not worried about supported deprecated APIs 
in old releases, only how long they stay around in master as that could be 
a barrier to innovation.
Right, so the cost would be an extra 8 months before removing features 
deprecated in 1.9 from master.

Thanks,
Collin

On Wednesday, June 10, 2015 at 2:09:13 PM UTC-4, Tim Graham wrote:
>
> Collin, I'm not following your reasoning about why dropping features 
> deprecated in one LTS (e.g. 1.8) in the next LTS (e.g. 2.1; I think you 
> made a typo in your timeline putting it next to 2.0?) will make it possible 
> to easily support both LTS releases? That's the purpose of Loic's proposal 
> I believe.
>
> For "maintenance costs" I am not worried about supported deprecated APIs 
> in old releases, only how long they stay around in master as that could be 
> a barrier to innovation.
>
> On Wednesday, June 10, 2015 at 1:54:53 PM UTC-4, Collin Anderson wrote:
>>
>> On Friday, May 8, 2015 at 12:12:37 PM UTC-4, Carl Meyer wrote:
>>>
>>> And there is a significant added maintenance cost to my proposal 
>>> compared to yours. Dropping deprecated APIs in the release after an LTS 
>>> means we still have to support those APIs for three more years (possibly 
>>> for four or five years after they were first deprecated). Dropping them 
>>> _in_ the LTS release shortens that window drastically.
>>
>>
>> If we release every 8 months, that means we normally support deprecated 
>> features for 2 years. If we maintained LTS compatibility, then, yes, that 
>> would mean "supporting" the APIs for more than 5 years after deprecation. 
>> But to be clear, most of that time it's only security support for those 
>> APIs, and the APIs are long gone from master. Right?
>>
>> Thanks,
>> Collin
>>
>>
>> On Wednesday, June 10, 2015 at 1:37:30 PM UTC-4, Collin Anderson wrote:
>>>
>>> Hi All,
>>>
>>> Here are some thoughts in reply to some of the comments in the 
>>> django-compat thread. I don't stick to the LTSs myself, but I've helped 
>>> maintain apps that have 1.4 compatibility.
>>>
>>> On Tuesday, June 9, 2015 at 7:05:45 PM UTC-4, Loïc Bistuer wrote:

 1.8 (LTS): No features dropped. 
 1.9: Dropped features deprecated in 1.4, 1.5, 1.6, 1.7 
 2.0: No features dropped. 
 2.1 (LTS): No features dropped. 
 2.2: Dropped features deprecated in 1.8, 1.9, 2.0 

>>>
>>> I'd propose something slightly different, that's very close to our 
>>> current deprecation timeline:
>>> 1.8 (LTS): No features dropped.
>>> 1.9: Dropped features deprecated in 1.5, 1.6, 1.7
>>> 2.0: Dropped features deprecated in 1.8
>>> 2.1 (LTS): No features dropped. 
>>> 2.2: Dropped features deprecated in 1.9, 2.0
>>> 2.3: Dropped features deprecated in 2.1
>>>
>>> Seems to me features deprecated in an LTS are fair game to disappear in 
>>> the next LTS. This allows us to remove "dotted paths in reverse() and 
>>> url()" because that's deprecated in 1.8.
>>>
>>> If we can guarantee compatibility between LTSs, I think that would be a 
>>> huge win, at the cost of extending the removal of some deprecated features 
>>> by one release (8 months). 
>>>
>>> Collin
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/512e9895-7216-4e0d-95dc-8c506c6646dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: how to deal with inspect.getargspec() deprecation?

[Marc Tamlyn]

I'm not sure how similar the return values are, is it possible to write
(and contribute upstream) a six move? Perhaps this is impossible without
funcsigs though.

Marc

On 10 June 2015 at 20:09, Carl Meyer  wrote:

> On 06/10/2015 12:49 PM, Tim Graham wrote:
> > inspect.getargspec() was deprecated in Python 3.0 and will be removed in
> > 3.6 (ETA late 2016). It started throwing a deprecation warning in Python
> > 3.5 which causes some test failures when we check the number of
> > deprecation warnings so I'd like to deal with it now and avoid
> > introducing more usages.
> >
> > Its replacement is inspect.signature() which is in all the versions of
> > Python 3 we support, but not 2.7. Options I see:
> > 1. Add a dependency for the funcsigs backport [1] (only needed on Python
> 2)
> > 2. Vendor funcsigs in django.utils (about 1k LOC) (this has been the
> > historical approach)
> > 3. Write different code for Python 2 & 3
> >
> > [1] https://github.com/aliles/funcsigs
>
> I'd say either 1 or 2. Personally I feel the ecosystem is ready for
> Django to have dependencies, and we could go with 1. But maybe a 1k LOC
> back-compat lib, which would likely be trivial to vendor, isn't the best
> case for that first required dependency.
>
> Carl
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/55788B4E.2060409%40oddbird.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1HgqEqjoU8%3DypQJpQJP%2BW1_xE0f1Q%3DH4CQv-_NoW2bYwQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Carl Meyer]

On 06/10/2015 11:54 AM, Collin Anderson wrote:
> On Friday, May 8, 2015 at 12:12:37 PM UTC-4, Carl Meyer wrote:
> 
> And there is a significant added maintenance cost to my proposal 
> compared to yours. Dropping deprecated APIs in the release after an LTS 
> means we still have to support those APIs for three more years
> (possibly 
> for four or five years after they were first deprecated). Dropping them 
> _in_ the LTS release shortens that window drastically.
> 
> 
> If we release every 8 months, that means we normally support deprecated
> features for 2 years. If we maintained LTS compatibility, then, yes,
> that would mean "supporting" the APIs for more than 5 years after
> deprecation. But to be clear, most of that time it's only security
> support for those APIs, and the APIs are long gone from master. Right?

Yes, that's correct. The longest a deprecated API would ever have to
remain in master, under my proposal, would be from one LTS (the one it
is first deprecated in) until immediately after the next LTS branches
off from master.

It's worth noting that I above framed "we still have to [security]
support those [deprecated] APIs for [X] more years" as a negative -
added maintenance cost. But we should remember that from the point of
view of a user of Django like the one who just posted in django-users,
who maintains large numbers of infrequently-updated Django sites, those
extra years of security support for deprecated APIs could feel like a
huge relief.

I'm not sure how often having a deprecated API still present in a
security-supported version would actually make a security fix more
difficult. Obviously it's only an issue at all if there's a security
problem in a closely-related area of the code. If there's a security
problem in the deprecated API itself, it could result in an extra
security release we wouldn't even have needed to make otherwise.

I do still think that allowing third-party apps to have a simple "we
support all supported Django versions" policy, without needing to
implement their own compatibility wrappers, and thus hopefully allowing
upgrading users to take a simpler "first update dependencies, then
update Django" approach to LTS->LTS updates (instead of "first update
dependencies part of the way, then update Django part of the way, then
update dependencies again, then update Django again"), are all
significant benefits to my/Loïc's proposal.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/55788DB6.3010003%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: how to deal with inspect.getargspec() deprecation?

[Carl Meyer]

On 06/10/2015 12:49 PM, Tim Graham wrote:
> inspect.getargspec() was deprecated in Python 3.0 and will be removed in
> 3.6 (ETA late 2016). It started throwing a deprecation warning in Python
> 3.5 which causes some test failures when we check the number of
> deprecation warnings so I'd like to deal with it now and avoid
> introducing more usages.
> 
> Its replacement is inspect.signature() which is in all the versions of
> Python 3 we support, but not 2.7. Options I see:
> 1. Add a dependency for the funcsigs backport [1] (only needed on Python 2)
> 2. Vendor funcsigs in django.utils (about 1k LOC) (this has been the
> historical approach)
> 3. Write different code for Python 2 & 3
> 
> [1] https://github.com/aliles/funcsigs

I'd say either 1 or 2. Personally I feel the ecosystem is ready for
Django to have dependencies, and we could go with 1. But maybe a 1k LOC
back-compat lib, which would likely be trivial to vendor, isn't the best
case for that first required dependency.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/55788B4E.2060409%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Minor Feature Request: Unconfigured Allowed_Hosts Setting Should Raise ImproperlyConfigured Error

[Tim Graham]

I forgot about the existing settings checks in django.conf__init__.py. That 
seems like a reasonable place.

Robert do you want to try to write a patch and/or open a ticket?

On Wednesday, June 10, 2015 at 2:38:31 PM UTC-4, Carl Meyer wrote:
>
> On 06/10/2015 11:55 AM, Tim Graham wrote: 
> > We added such a check in runserver [1]. 
>
> Unfortunately, this doesn't help for the (likely) most common case of 
> "local dev with runserver and DEBUG=True, deployment with another server 
> and DEBUG=False". 
>
> > For other servers it seems less 
> > clear to me where that check would go -- in the WSGI handler? In 
> > django.setup()? 
>
> I was thinking django.setup() or directly in django.conf.settings. 
>
> > (obviously, there is no need for ALLOWED_HOSTS if you 
> > are using Django outside a webserver context, so the check could be 
> > annoying if it's there). 
>
> Yes, this is true. I guess we have to weigh the debugging issues caused 
> by not having such a check against the (rare?) case of someone running 
> Django in a non-request-serving capacity with a different settings file 
> from the one they use to serve requests. (It's that latter clause that 
> makes it seem a rare case to me - normally when you run e.g. Celery or 
> some other type of worker process, you'd want to run it with exactly the 
> same settings as your request-serving processes, in order to avoid other 
> inconsistencies causing problems.) 
>
> And the workaround for the annoying case would be simple - just go ahead 
> and configure ALLOWED_HOSTS to something non-empty, even though you 
> technically don't need it. 
>
> Carl 
>
> > [1] https://code.djangoproject.com/ticket/19875 
> > 
> > On Wednesday, June 10, 2015 at 1:40:11 PM UTC-4, Carl Meyer wrote: 
> > 
> > On 06/10/2015 09:55 AM, Robert Roskam wrote: 
> > > I realize this is a simple thing, but I'm sure this will save some 
> > > people time. 
> > > 
> > > Since Allowed_Hosts is a required setting, when debug mode is off, 
> it 
> > > should raise an appropriate ImproperlyConfigured error. 
> > > 
> > > I'm sure there's some broader discussion surrounding which 
> settings 
> > > should have this and why, but I haven't been able to find it. 
> > 
> > This makes sense - a configuration with DEBUG=False and empty 
> > ALLOWED_HOSTS can't possibly work, so why should we even allow it to 
> > start up? Can anyone else recall a reason why we didn't do this? 
> > 
> > Carl 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Django developers (Contributions to Django itself)" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> > an email to django-develop...@googlegroups.com  
> > . 
> > To post to this group, send email to django-d...@googlegroups.com 
>  
> > . 
> > Visit this group at http://groups.google.com/group/django-developers. 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/django-developers/c4af417b-4775-4fda-90ad-f6bf2c93f9b2%40googlegroups.com
>  
> > <
> https://groups.google.com/d/msgid/django-developers/c4af417b-4775-4fda-90ad-f6bf2c93f9b2%40googlegroups.com?utm_medium=email_source=footer>.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3d6e7090-60af-4401-8ffd-0b8991d7dc17%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Minor Feature Request: Unconfigured Allowed_Hosts Setting Should Raise ImproperlyConfigured Error

[Carl Meyer]

On 06/10/2015 11:55 AM, Tim Graham wrote:
> We added such a check in runserver [1]. 

Unfortunately, this doesn't help for the (likely) most common case of
"local dev with runserver and DEBUG=True, deployment with another server
and DEBUG=False".

> For other servers it seems less
> clear to me where that check would go -- in the WSGI handler? In
> django.setup()? 

I was thinking django.setup() or directly in django.conf.settings.

> (obviously, there is no need for ALLOWED_HOSTS if you
> are using Django outside a webserver context, so the check could be
> annoying if it's there).

Yes, this is true. I guess we have to weigh the debugging issues caused
by not having such a check against the (rare?) case of someone running
Django in a non-request-serving capacity with a different settings file
from the one they use to serve requests. (It's that latter clause that
makes it seem a rare case to me - normally when you run e.g. Celery or
some other type of worker process, you'd want to run it with exactly the
same settings as your request-serving processes, in order to avoid other
inconsistencies causing problems.)

And the workaround for the annoying case would be simple - just go ahead
and configure ALLOWED_HOSTS to something non-empty, even though you
technically don't need it.

Carl

> [1] https://code.djangoproject.com/ticket/19875
> 
> On Wednesday, June 10, 2015 at 1:40:11 PM UTC-4, Carl Meyer wrote:
> 
> On 06/10/2015 09:55 AM, Robert Roskam wrote:
> > I realize this is a simple thing, but I'm sure this will save some
> > people time.
> >
> > Since Allowed_Hosts is a required setting, when debug mode is off, it
> > should raise an appropriate ImproperlyConfigured error.
> >
> > I'm sure there's some broader discussion surrounding which settings
> > should have this and why, but I haven't been able to find it.
> 
> This makes sense - a configuration with DEBUG=False and empty
> ALLOWED_HOSTS can't possibly work, so why should we even allow it to
> start up? Can anyone else recall a reason why we didn't do this?
> 
> Carl
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-developers+unsubscr...@googlegroups.com
> .
> To post to this group, send email to django-developers@googlegroups.com
> .
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/c4af417b-4775-4fda-90ad-f6bf2c93f9b2%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/55788416.8070102%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: 1.9 release planning

[Tim Graham]

Collin, I'm not following your reasoning about why dropping features 
deprecated in one LTS (e.g. 1.8) in the next LTS (e.g. 2.1; I think you 
made a typo in your timeline putting it next to 2.0?) will make it possible 
to easily support both LTS releases? That's the purpose of Loic's proposal 
I believe.

For "maintenance costs" I am not worried about supported deprecated APIs in 
old releases, only how long they stay around in master as that could be a 
barrier to innovation.

On Wednesday, June 10, 2015 at 1:54:53 PM UTC-4, Collin Anderson wrote:
>
> On Friday, May 8, 2015 at 12:12:37 PM UTC-4, Carl Meyer wrote:
>>
>> And there is a significant added maintenance cost to my proposal 
>> compared to yours. Dropping deprecated APIs in the release after an LTS 
>> means we still have to support those APIs for three more years (possibly 
>> for four or five years after they were first deprecated). Dropping them 
>> _in_ the LTS release shortens that window drastically.
>
>
> If we release every 8 months, that means we normally support deprecated 
> features for 2 years. If we maintained LTS compatibility, then, yes, that 
> would mean "supporting" the APIs for more than 5 years after deprecation. 
> But to be clear, most of that time it's only security support for those 
> APIs, and the APIs are long gone from master. Right?
>
> Thanks,
> Collin
>
>
> On Wednesday, June 10, 2015 at 1:37:30 PM UTC-4, Collin Anderson wrote:
>>
>> Hi All,
>>
>> Here are some thoughts in reply to some of the comments in the 
>> django-compat thread. I don't stick to the LTSs myself, but I've helped 
>> maintain apps that have 1.4 compatibility.
>>
>> On Tuesday, June 9, 2015 at 7:05:45 PM UTC-4, Loïc Bistuer wrote:
>>>
>>> 1.8 (LTS): No features dropped. 
>>> 1.9: Dropped features deprecated in 1.4, 1.5, 1.6, 1.7 
>>> 2.0: No features dropped. 
>>> 2.1 (LTS): No features dropped. 
>>> 2.2: Dropped features deprecated in 1.8, 1.9, 2.0 
>>>
>>
>> I'd propose something slightly different, that's very close to our 
>> current deprecation timeline:
>> 1.8 (LTS): No features dropped.
>> 1.9: Dropped features deprecated in 1.5, 1.6, 1.7
>> 2.0: Dropped features deprecated in 1.8
>> 2.1 (LTS): No features dropped. 
>> 2.2: Dropped features deprecated in 1.9, 2.0
>> 2.3: Dropped features deprecated in 2.1
>>
>> Seems to me features deprecated in an LTS are fair game to disappear in 
>> the next LTS. This allows us to remove "dotted paths in reverse() and 
>> url()" because that's deprecated in 1.8.
>>
>> If we can guarantee compatibility between LTSs, I think that would be a 
>> huge win, at the cost of extending the removal of some deprecated features 
>> by one release (8 months). 
>>
>> Collin
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d1fa4a97-1662-4e8b-9cba-c047ba63e141%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Minor Feature Request: Unconfigured Allowed_Hosts Setting Should Raise ImproperlyConfigured Error

[Tim Graham]

We added such a check in runserver [1]. For other servers it seems less 
clear to me where that check would go -- in the WSGI handler? In 
django.setup()? (obviously, there is no need for ALLOWED_HOSTS if you are 
using Django outside a webserver context, so the check could be annoying if 
it's there).

[1] https://code.djangoproject.com/ticket/19875

On Wednesday, June 10, 2015 at 1:40:11 PM UTC-4, Carl Meyer wrote:
>
> On 06/10/2015 09:55 AM, Robert Roskam wrote: 
> > I realize this is a simple thing, but I'm sure this will save some 
> > people time. 
> > 
> > Since Allowed_Hosts is a required setting, when debug mode is off, it 
> > should raise an appropriate ImproperlyConfigured error. 
> > 
> > I'm sure there's some broader discussion surrounding which settings 
> > should have this and why, but I haven't been able to find it. 
>
> This makes sense - a configuration with DEBUG=False and empty 
> ALLOWED_HOSTS can't possibly work, so why should we even allow it to 
> start up? Can anyone else recall a reason why we didn't do this? 
>
> Carl 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c4af417b-4775-4fda-90ad-f6bf2c93f9b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Collin Anderson]

On Friday, May 8, 2015 at 12:12:37 PM UTC-4, Carl Meyer wrote:
>
> And there is a significant added maintenance cost to my proposal 
> compared to yours. Dropping deprecated APIs in the release after an LTS 
> means we still have to support those APIs for three more years (possibly 
> for four or five years after they were first deprecated). Dropping them 
> _in_ the LTS release shortens that window drastically.


If we release every 8 months, that means we normally support deprecated 
features for 2 years. If we maintained LTS compatibility, then, yes, that 
would mean "supporting" the APIs for more than 5 years after deprecation. 
But to be clear, most of that time it's only security support for those 
APIs, and the APIs are long gone from master. Right?

Thanks,
Collin


On Wednesday, June 10, 2015 at 1:37:30 PM UTC-4, Collin Anderson wrote:
>
> Hi All,
>
> Here are some thoughts in reply to some of the comments in the 
> django-compat thread. I don't stick to the LTSs myself, but I've helped 
> maintain apps that have 1.4 compatibility.
>
> On Tuesday, June 9, 2015 at 7:05:45 PM UTC-4, Loïc Bistuer wrote:
>>
>> 1.8 (LTS): No features dropped. 
>> 1.9: Dropped features deprecated in 1.4, 1.5, 1.6, 1.7 
>> 2.0: No features dropped. 
>> 2.1 (LTS): No features dropped. 
>> 2.2: Dropped features deprecated in 1.8, 1.9, 2.0 
>>
>
> I'd propose something slightly different, that's very close to our current 
> deprecation timeline:
> 1.8 (LTS): No features dropped.
> 1.9: Dropped features deprecated in 1.5, 1.6, 1.7
> 2.0: Dropped features deprecated in 1.8
> 2.1 (LTS): No features dropped. 
> 2.2: Dropped features deprecated in 1.9, 2.0
> 2.3: Dropped features deprecated in 2.1
>
> Seems to me features deprecated in an LTS are fair game to disappear in 
> the next LTS. This allows us to remove "dotted paths in reverse() and 
> url()" because that's deprecated in 1.8.
>
> If we can guarantee compatibility between LTSs, I think that would be a 
> huge win, at the cost of extending the removal of some deprecated features 
> by one release (8 months). 
>
> Collin
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d3fabc7e-6811-4a85-96c4-fdc651e366cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Template-based widget rendering

[Preston Timmons]

Hi all,

I've been working through solutions for #15667 -- template based widget
rendering. This is a problem that was close to a solution at one time, but
stalled out due to performance concerns and difficulties with defining a
workable API to create configurable template loaders.

Now that Jinja2 is supported, performance isn't as much a concern. So,
I'd like to tackle the API portion of this.

This problem has two sides:

1) Converting individual widgets to be rendered with templates.
2) Deciding how to instantiate a user-customizable template engine.

The first is easy to accomplish, but the second isn't. I've written a
proposal for the second problem available here:

https://gist.github.com/prestontimmons/24a2a835bea590afb70b

In addition, a WIP branch is available here:

https://github.com/prestontimmons/django/tree/ticket-15667

Hopefully, we can finally get this in. :)

Preston

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c0ea2593-05c2-4307-86ea-1b34c05d0f7a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Minor Feature Request: Unconfigured Allowed_Hosts Setting Should Raise ImproperlyConfigured Error

[Carl Meyer]

On 06/10/2015 09:55 AM, Robert Roskam wrote:
> I realize this is a simple thing, but I'm sure this will save some
> people time.
> 
> Since Allowed_Hosts is a required setting, when debug mode is off, it
> should raise an appropriate ImproperlyConfigured error.
> 
> I'm sure there's some broader discussion surrounding which settings
> should have this and why, but I haven't been able to find it.

This makes sense - a configuration with DEBUG=False and empty
ALLOWED_HOSTS can't possibly work, so why should we even allow it to
start up? Can anyone else recall a reason why we didn't do this?

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5578766B.6030707%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: 1.9 release planning

[Collin Anderson]

Hi All,

Here are some thoughts in reply to some of the comments in the 
django-compat thread. I don't stick to the LTSs myself, but I've helped 
maintain apps that have 1.4 compatibility.

On Tuesday, June 9, 2015 at 7:05:45 PM UTC-4, Loïc Bistuer wrote:
>
> 1.8 (LTS): No features dropped. 
> 1.9: Dropped features deprecated in 1.4, 1.5, 1.6, 1.7 
> 2.0: No features dropped. 
> 2.1 (LTS): No features dropped. 
> 2.2: Dropped features deprecated in 1.8, 1.9, 2.0 
>

I'd propose something slightly different, that's very close to our current 
deprecation timeline:
1.8 (LTS): No features dropped.
1.9: Dropped features deprecated in 1.5, 1.6, 1.7
2.0: Dropped features deprecated in 1.8
2.1 (LTS): No features dropped. 
2.2: Dropped features deprecated in 1.9, 2.0
2.3: Dropped features deprecated in 2.1

Seems to me features deprecated in an LTS are fair game to disappear in the 
next LTS. This allows us to remove "dotted paths in reverse() and url()" 
because that's deprecated in 1.8.

If we can guarantee compatibility between LTSs, I think that would be a 
huge win, at the cost of extending the removal of some deprecated features 
by one release (8 months). 

Collin

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/586e0962-f73f-40b5-9113-8a703f9afd68%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Minor Feature Request: Unconfigured Allowed_Hosts Setting Should Raise ImproperlyConfigured Error

[Robert Roskam]

I realize this is a simple thing, but I'm sure this will save some people 
time.

Since Allowed_Hosts is a required setting, when debug mode is off, it 
should raise an appropriate ImproperlyConfigured error.

I'm sure there's some broader discussion surrounding which settings should 
have this and why, but I haven't been able to find it.

Robert

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fe4359c0-f2c7-49ea-a1de-5b35f3980f2c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add support for unsigned primary keys in MySQL

[Andrew Godwin]

I agree with Loïc that this problem is probably best solved when the
virtual/composite stuff is finally sorted out; I don't want us to put in a
quicker fix that's not going to match those, and that's already going to
have to deal with things like composite keys and potentially changing FKs
anyway.

As for the migration end, we can handle it somehow. My first thought would
be to compare FK types from the migration and from the models in the
migration autodetector and emit changes there if needed, as two or three
parts (separate out dropping the FK constraint separately, and make it run
before the main PK change).

Andrew

On Wed, Jun 10, 2015 at 3:50 AM, Loïc Bistuer 
wrote:

> I think we can link https://code.djangoproject.com/ticket/56 to
> https://code.djangoproject.com/ticket/14286.
>
> The problem is not so much how to create an UnsignedAutoField or a
> BigAutoField which is rather trivial, but how to deal with foreign keys
> pointing to them and how to migrate them. As far as I know it's the only
> case where changing one field requires migrations in multiple apps, and
> since you don't necessarily have the source repo available for them, it's
> not clear how we can handle it.
>
> There is also a design issue, do we want AutoField + UnsignedAutoField +
> BigAutoField + UnsignedBigAutoField and their ForeignKey counterparts?
> That's ugly IMO. We could have AutoField(storage=models.IntegerField) which
> is slightly better, or we could wait to have nailed the Virtual/Composite
> API and AutoField would become virtual and use the same API as composite
> fields to pick its backing field (e.g. id = BigIntegerFIeld(); pk =
> AutoField(concrete='id')).
>
> All in all, I'm not for a wontfix, but as with any low digits tickets a
> proper fix is far from easy.
>
> --
> Loïc
>
> > On Jun 10, 2015, at 11:50, Markus Amalthea Magnuson <
> markus.magnu...@gmail.com> wrote:
> >
> > I've picked up this old ticket:
> >
> > https://code.djangoproject.com/ticket/56
> >
> > After some initial discussions on #django-dev it seems like wontfixing
> it would be an option too, so I wanted to ask about core devs' view on this:
> >
> > Is implementing opt-in support for unsigned primary keys on MySQL still
> interesting?
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Django developers (Contributions to Django itself)" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to django-developers+unsubscr...@googlegroups.com.
> > To post to this group, send email to django-developers@googlegroups.com.
> > Visit this group at http://groups.google.com/group/django-developers.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAOXH8SX2gdM3OSDYkY7W94MVac%2Bh9Wo68r2qaRzisbEiYOzhoA%40mail.gmail.com
> .
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/76CE4389-DE36-4FBA-9E49-02ED5AFAFF9D%40gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1uof_YC23HU%3DEi%2B2kANve1-Z8gB4sTE8_ri5ekmUUN26_A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making management forms for formsets optional

[Patryk Zawadzki]

2015-06-08 20:22 GMT+02:00 Carl Meyer :
> But I think such a project needs to be approached as a full rewrite,
> probably first as a third-party module and then later (if it works out
> well) considered for merge as a separate replacement module. It does not
> seem likely to me that tugging on individual threads like "remove
> management form" and "remove initial forms" will result in changes to
> the current formset code that are both backwards-compatible and an
> improvement in the design. I'm willing to be proven wrong, but so far
> the current pull request only strengthens that feeling.

This could very well be true. We could also try implementing a field
wrapping a subform and a field wrapping a multitude of fields. I am
not sure whether there would be an obvious way to render the resultin
form as HTML but it would mean that we'd end up only having a single
thing to deal with (forms) and would allow existing views to
transparently handle situations where more than one form is needed
(just create a form that consists of two subform fields).

-- 
Patryk Zawadzki
I solve problems.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANw2pUEM9q%2BbWymWATKhoXSU9eSw3jagVY5bjVJhGGrqzv-zdw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Form assets and static file storage

[Tim Graham]

The problem has come up before:
https://code.djangoproject.com/ticket/18455

but there is some question about whether the design of the Media class is 
something we should try to continue building on:
https://code.djangoproject.com/ticket/22298

The suggestion to have the built-in static tag work like admin_static does 
seem like a practical one. The question is whether practicality beats 
purity (keeping contrib dependencies, albeit a conditional one in this 
case, out of core) in this case. I'd say yes, unless there's a suitable 
alternate proposal to address the problem.

On Tuesday, June 9, 2015 at 5:01:53 PM UTC-4, Collin Anderson wrote:
>
> Hi Dom,
>
> Yeah, it looks like the admin_static is simply uses the staticfiles tag if 
> staticfiles is installed, otherwise falls back to the core static? The only 
> reason why it admin_static exists is because the admin can't rely on 
> staticfiles being installed, right? Maybe pulling the the staticfiles tag 
> into builtins would help?
>
> Collin
>
> On Tuesday, June 9, 2015 at 4:51:50 PM UTC-4, Dominic Rodger wrote:
>>
>> I recently came across a problem when using ManifestStaticFilesStorage on 
>> an app with form media, which the documentation doesn't seem to address. 
>> I'm posting here rather that on django-users, since I think we ought to at 
>> least document how to fix it, or preferably come up with a better way of 
>> solving it.
>>
>> The app I was using is django-image-cropping, which specifies the media 
>> for a widget like this (see image_cropping/widgets.py#L60 
>> 
>> ):
>>
>> def _media(self):
>> js = [
>> "image_cropping/js/jquery.Jcrop.min.js",
>> "image_cropping/image_cropping.js",
>> ]
>>
>> css = {'all': ("image_cropping/css/jquery.Jcrop.min.css",
>>"image_cropping/css/image_cropping.css",)}
>> return forms.Media(css=css, js=js)
>>
>> media = property(_media)
>>
>> When rendered to HTML, it generates a static path (i.e. STATIC_URL is 
>> prepended), but doesn't correctly generate paths to minified content, so 
>> you get 404s. django.contrib.admin has worked around this - by using the 
>> admin_static template tag (see 
>> django/contrib/admin/templatetags/admin_static.py#L10 
>> ).
>>  
>> I fixed up django-image-cropping by porting that workaround to the app 
>> itself (see PR 
>> ), but 
>> it feels like it might be worth documenting how people should be handling 
>> this in their apps. I'm thinking of something along the lines of making the 
>> code in admin_static.py less admin specific (so far as I can see, it 
>> doesn't actually have anything to do with django.contrib.admin) - perhaps 
>> exposing the functionality in django.utils, and then having the templatetag 
>> admin_static use that function.
>>
>> If I've missed something, my apologies, but I couldn't find any tickets 
>> related to this. It seems like something others would have come across 
>> already, so again, apologies if there's already a ticket for this, or if 
>> I've gone about this in a braindead way.
>>
>> If patches/tickets need writing, I'd be happy to get stuck in - just 
>> wanted some clarity that I'm not crazy first :)
>>
>> Dom
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8896a109-ce56-413a-9fb6-ef50fc5c96c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin - ModelAdmin exclude

[Tim Graham]

I agree with Marc that so many ways to do things isn't ideal, but I don't 
see a different simple way to accommodate Peter's use case, so +0 to adding 
get_exclude().

On Saturday, June 6, 2015 at 11:44:53 AM UTC-4, Peter J. Farrell wrote:
>
> In our case, we need to dynamically include additional "exclude" fields in 
> our VersionableAdmin and not override the selections the developer has set 
> in their subclass.  There are two options to accomplished this:
>
> 1) Override get_form() which is messy because you can't just call super 
> here and modify things.  This is a lot of code duplication to just get at 
> the exclude
>
> def get_form(self, request, obj=None, **kwargs):
> """
> Returns a Form class for use in the admin add view. This is used by
> add_view and change_view.
> """
> if 'fields' in kwargs:
> fields = kwargs.pop('fields')
> else:
> fields = flatten_fieldsets(self.get_fieldsets(request, obj))
> if self.exclude is None:
> exclude = []
> else:
> exclude = list(self.exclude)
> exclude.extend(self.get_readonly_fields(request, obj))
> if self.exclude is None and hasattr(self.form, '_meta') and 
> self.form._meta.exclude:
> # Take the custom ModelForm's Meta.exclude into account only if the
> # ModelAdmin doesn't define its own.
> exclude.extend(self.form._meta.exclude)
> # if exclude is an empty list we pass None to be consistent with the
> # default on modelform_factory
> exclude = exclude or None
> defaults = {
> "form": self.form,
> "fields": fields,
> "exclude": exclude,
> "formfield_callback": partial(self.formfield_for_dbfield, 
> request=request),
> }
> defaults.update(kwargs)
>
> if defaults['fields'] is None and not 
> modelform_defines_fields(defaults['form']):
> defaults['fields'] = forms.ALL_FIELDS
>
> try:
> return modelform_factory(self.model, **defaults)
> except FieldError as e:
> raise FieldError('%s. Check fields/fieldsets/exclude attributes of 
> class %s.'
>  % (e, self.__class__.__name__))
>
>
> 2) Build your own descriptor for exclude:
>
> @property
> def exclude(self):
> """
> Custom descriptor for exclude since there is no get_exclude method to be 
> overridden
> """
> exclude = self.VERSIONED_EXCLUDE
>
> if super(VersionedAdmin, self).exclude is not None:
> # Force cast to list as super exclude could return a tuple
> exclude = list(super(VersionedAdmin, self).exclude) + exclude
>
> return exclude
>
>
> But then this trips the _check_exclude check in ModelAdminChecks for not 
> being a list or tuple. So you have to subclass that:
>
> class VersionedAdminChecks(ModelAdminChecks):
> def _check_exclude(self, cls, model):
> """
> Required to suppress error about exclude not being a tuple since we 
> are using @property to dynamically change it
> """
> return []
>
>
> All of this is a lot of effort just to get at dynamic exclude where 
> get_exclude() fits the current pattern used in the admin in the current 
> code base.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6b36c786-deb1-4878-a94e-1f6487c95c18%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add support for unsigned primary keys in MySQL

[Loïc Bistuer]

I think we can link https://code.djangoproject.com/ticket/56 to 
https://code.djangoproject.com/ticket/14286.

The problem is not so much how to create an UnsignedAutoField or a BigAutoField 
which is rather trivial, but how to deal with foreign keys pointing to them and 
how to migrate them. As far as I know it's the only case where changing one 
field requires migrations in multiple apps, and since you don't necessarily 
have the source repo available for them, it's not clear how we can handle it.

There is also a design issue, do we want AutoField + UnsignedAutoField + 
BigAutoField + UnsignedBigAutoField and their ForeignKey counterparts? That's 
ugly IMO. We could have AutoField(storage=models.IntegerField) which is 
slightly better, or we could wait to have nailed the Virtual/Composite API and 
AutoField would become virtual and use the same API as composite fields to pick 
its backing field (e.g. id = BigIntegerFIeld(); pk = AutoField(concrete='id')).

All in all, I'm not for a wontfix, but as with any low digits tickets a proper 
fix is far from easy.

-- 
Loïc

> On Jun 10, 2015, at 11:50, Markus Amalthea Magnuson 
>  wrote:
> 
> I've picked up this old ticket:
> 
> https://code.djangoproject.com/ticket/56
> 
> After some initial discussions on #django-dev it seems like wontfixing it 
> would be an option too, so I wanted to ask about core devs' view on this:
> 
> Is implementing opt-in support for unsigned primary keys on MySQL still 
> interesting?
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAOXH8SX2gdM3OSDYkY7W94MVac%2Bh9Wo68r2qaRzisbEiYOzhoA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/76CE4389-DE36-4FBA-9E49-02ED5AFAFF9D%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Add support for unsigned primary keys in MySQL

[Markus Amalthea Magnuson]

I've picked up this old ticket:

https://code.djangoproject.com/ticket/56

After some initial discussions on #django-dev it seems like wontfixing it
would be an option too, so I wanted to ask about core devs' view on this:

Is implementing opt-in support for unsigned primary keys on MySQL still
interesting?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAOXH8SX2gdM3OSDYkY7W94MVac%2Bh9Wo68r2qaRzisbEiYOzhoA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Introducing django-compat - arteria's solution for for- and backwards compatibility from Django 1.4.x to 1.8.x/1.9.x

[Philippe O. Wagner]

Hi all, 

I'd like to highlight these two points from the OP:

* Eliminate code duplication from app to app and handle them in one 
central place.
* Have a stable and testet single library that handles these compatible 
objects ...

It's not only about the version to version support, but also to follow the 
DRY principle and support other 3rd party apps. It follows the same idea 
like six does for Python 2.x to Python 3.x compatibility. 

BTW, good point Loïc about "providing an upgrade path" and keep the 
intermediate versions even not for production. We will keep this in mind 
for django-compat.

Tim, from my point of view it's not the number, 25% in this case, that 
matters. It depends who starts with the latest greatest version and who use 
the LTS.  I think agencies with a lot of customer and big, complex projects 
will/tend to build on a LTS version. These numbers depends totally who 
answers the survey.




Am Mittwoch, 10. Juni 2015 02:02:15 UTC+2 schrieb Tim Graham:
>
> Carl proposed a similar thing: 
> https://groups.google.com/d/msg/django-developers/qCjfOu-FPxQ/hccAcVChHMkJ
> It would be a bit better than he outlined there with an LTS every 2 years 
> instead of 3 as I proposed.
>
> It seems difficult to estimate how much such a policy would increase 
> maintenance costs in Django itself. The current proposal already keeps 
> features deprecated in 1.8 around an extra 8 months compared to the old 
> scheme. Your suggestion extends this to 16 months (and for features 
> deprecated in 1.9, an extra 8 months too). An interesting exercise would be 
> to look through the features deprecated in 1.8 and try to guesstimate the 
> maintenance costs of keeping them around longer. I guess such estimation 
> will be basically impossible though -- only when working on new features 
> will we realize if supporting old APIs will be annoying or a problem. The 
> only thing that comes to my mind is dotted paths in reverse() and url() -- 
> once we can remove that stuff the URL resolver is quick a bit simpler and I 
> know Marten was planning for that to be gone with his GSoC URL proposal 
> (although I guess the new API can probably be implemented without support 
> for that anyway).
>
> For what it's worth, about 25% of survey respondents indicated when 
> starting a new project they use LTS as opposed to the latest stable 
> version. Are the benefits to that fraction of the community large enough to 
> outweigh the costs?
>
> On Tuesday, June 9, 2015 at 7:05:45 PM UTC-4, Loïc Bistuer wrote:
>>
>> Thanks Philippe for bringing this up. 
>>
>> I'm currently upgrading a large Django app with dozens of dependencies 
>> from 1.4 to 1.8, here are some observations: 
>> - Most popular and/or maintained libraries actually supports every Django 
>> version between 1.4 to 1.8. (Many thanks to their maintainers!) 
>> - Libraries that support 1.4 and 1.8 but not with a single version add a 
>> lot more overhead to the upgrade process. 
>> - Libraries have their own backwards incompatibilities and deprecations. 
>> By itself it's easily manageable when the new version still support your 
>> current Django version, but it gets messy when you need to upgrade both 
>> Django and 3rd-party apps at the same time. 
>>
>> Obviously, no production projects should depend on an unsupported version 
>> of Django, but you still need to upgrade to intermediary versions as you 
>> work your way to the latest LTS. 3rd-party apps that support both LTS have 
>> been a huge help to us: you can upgrade them making changes to your project 
>> as required, then they stay out of the way when you upgrade Django itself. 
>> I wouldn't consider that libraries still supporting Django 1.5 are 
>> encouraging running unsupported versions of Django, they are just providing 
>> an upgrade path. Without such upgrade paths in the Django ecosystem, I 
>> think LTS while good on paper, are a bad idea in practice. 
>>
>> The new proposal to have an LTS every third release is an improvement 
>> over the current situation since 3rd-party apps need to support one less 
>> version to bridge between two LTS. But I'm not convinced with "deprecated 
>> features won’t be dropped until the version those features were deprecated 
>> in is no longer supported"; it adds overhead to Django's maintenance while 
>> still requiring 3rd-party apps to create shims if they want to support both 
>> LTS to ease with the upgrade process. 
>>
>> How about dropping all the shims in the release immediately following an 
>> LTS? For example (slightly rewriting the past): 
>>   
>> 1.8 (LTS): No features dropped. 
>> 1.9: Dropped features deprecated in 1.4, 1.5, 1.6, 1.7 
>> 2.0: No features dropped. 
>> 2.1 (LTS): No features dropped. 
>> 2.2: Dropped features deprecated in 1.8, 1.9, 2.0 
>>
>> Cheers 
>>
>> -- 
>> Loïc 
>>
>> > On Jun 3, 2015, at 16:53, Philippe O. Wagner  
>> wrote: 
>> > 
>> > Thanks Tim for your response and