Hello,
On 8 mai 2015, at 17:54, Carl Meyer wrote:
>
> On 05/07/2015 10:20 PM, Tai Lee wrote:
>> This sounds good. But will it significantly slow down the rollout of new
>> features into Django that require deprecation?
>
> No, because it would only delay the removal of deprecated features, not
Hi Tim,
On 05/08/2015 08:28 AM, Tim Graham wrote:
> Do we need to make it easy to support two LTS releases at once? For
> example, at this point in time I expect projects to drop 1.4 support
> when adding 1.8 support, not try to support both given that 1.4 will be
> EOL in < 6 months. Assuming the
Hi Tai,
On 05/07/2015 10:20 PM, Tai Lee wrote:
> This sounds good. But will it significantly slow down the rollout of new
> features into Django that require deprecation?
No, because it would only delay the removal of deprecated features, not
prevent the initial deprecation. The only cost here is
Do we need to make it easy to support two LTS releases at once? For
example, at this point in time I expect projects to drop 1.4 support when
adding 1.8 support, not try to support both given that 1.4 will be EOL in <
6 months. Assuming the answer is no, practically, it might mean keeping
aroun
This sounds good. But will it significantly slow down the rollout of new
features into Django that require deprecation? Also, could features that
are deprecated in an LTS be dropped in the next non-LTS release? e.g. if
1.8 still had a feature that was deprecated in 1.5, could it finally be
remo
On 05/07/2015 08:53 AM, Tim Graham wrote:
> I think there is some merit to reconsidering the deprecation schedule as
> Anssi suggests. What I have seen is that most third-party apps didn't
> consider dropping support for the previous LTS (1.4) until the next LTS
> (1.8) was released. This meant tha
I think there is some merit to reconsidering the deprecation schedule as
Anssi suggests. What I have seen is that most third-party apps didn't
consider dropping support for the previous LTS (1.4) until the next LTS
(1.8) was released. This meant that all these projects had to implement
their ow
You only get painless upgrades from one LTS to the next *if* you don't have
any deprecation warnings in your code on the previous LTS. Whilst the
"getting it working" step from one LTS direct to the next should be fairly
easy, you're likely to be faced with just as large a set of deprecation
issues
On Thu, May 7, 2015 at 11:34 AM, Marc Tamlyn wrote:
> I'm not sure that would be a wise move - for people who don't keep up with
> deprecation warnings but otherwise move one version at a time it would make
> upgrading from an LTS to the following release 3 times harder than normal,
> encouraging
On Thu, May 7, 2015 at 9:04 AM, Abdullah Esmail
wrote:
> Hello,
> I apologize if this has been discussed already. I searched the topics, but
> didn't find anything.
> First, I'd like to thank all of you for the truly amazing framework. I've
> been using django since 1.0 and it made my life much mo
I'm not sure that would be a wise move - for people who don't keep up with
deprecation warnings but otherwise move one version at a time it would make
upgrading from an LTS to the following release 3 times harder than normal,
encouraging stagnation. This also affects third party applications who wi
One approach worth consideration is dropping deprecated features only
after next LTS. This would mean that any non-deprecated feature that
is available in current LTS will also be available (but possibly
deprecated) in the next LTS. This should make a development model
where code is developed using
Hello,
I apologize if this has been discussed already. I searched the topics, but
didn't find anything.
First, I'd like to thank all of you for the truly amazing framework. I've
been using django since 1.0 and it made my life much more easier and
enjoyable and _stable_.
The reason why I love dj
13 matches
Mail list logo
