+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.
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 bec
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ğ wro
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 AP
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:
>
> H
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
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
>
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 l
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 c
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
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
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 supp
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 dea
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 add
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
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 whe
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 b
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 the
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 f
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
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 di
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:
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
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.
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 indi
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 l
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
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 fa
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
int
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 sup
30 matches
Mail list logo
