Re: deprecation vs removal

2011-10-04 Thread ptone
On Oct 1, 9:10 am, Luke Plant wrote: > Hi all, > > The Django deprecation timeline [1] is very inconsistent in its usage of > the terminology 'deprecated'. For example, the 1.5 section often says > "is  deprecated" or "has been deprecated", when what they mean is "will >

Re: deprecation vs removal

2011-10-04 Thread Luke Plant
On 04/10/11 05:56, Tai Lee wrote: > > > On Oct 4, 11:17 am, Russell Keith-Magee > wrote: >> I'm completely agreed that the 'soft' deprecation is useful. I'm just >> complaining about the ambiguity in the language: "We're deprecating >> this feature by marking it

Re: deprecation vs removal

2011-10-03 Thread Justin Holmes
or PendingRemoval? On Mon, Oct 3, 2011 at 9:56 PM, Tai Lee wrote: > > > On Oct 4, 11:17 am, Russell Keith-Magee > wrote: >> I'm completely agreed that the 'soft' deprecation is useful. I'm just >> complaining about the ambiguity in the

Re: deprecation vs removal

2011-10-03 Thread Tai Lee
On Oct 4, 11:17 am, Russell Keith-Magee wrote: > I'm completely agreed that the 'soft' deprecation is useful. I'm just > complaining about the ambiguity in the language: "We're deprecating > this feature by marking it PendingDeprecation...". What about just changing

Re: deprecation vs removal

2011-10-03 Thread Russell Keith-Magee
On Tue, Oct 4, 2011 at 9:40 AM, Joe & Anne Tennies wrote: > I know that no one knows who I am, but I'm going to say that this is > becoming a bike shed. There appears to be some confusion here -- nobody is proposing changing *anything* about Django's deprecation policy. All we

Re: deprecation vs removal

2011-10-03 Thread Joe & Anne Tennies
I know that no one knows who I am, but I'm going to say that this is becoming a bike shed. It sounds like there's generally agreement that people need to be warned that something is going to be removed. It sounds like people that maintain code that is required to be stable and relies on other

Re: deprecation vs removal

2011-10-03 Thread Russell Keith-Magee
On Tue, Oct 4, 2011 at 12:27 AM, ptone wrote: > > > On Oct 1, 9:10 am, Luke Plant wrote: >> Hi all, >> >> The Django deprecation timeline [1] is very inconsistent in its usage of >> the terminology 'deprecated'. For example, the 1.5 section often says >>

Re: deprecation vs removal

2011-10-03 Thread ptone
On Oct 1, 9:10 am, Luke Plant wrote: > Hi all, > > The Django deprecation timeline [1] is very inconsistent in its usage of > the terminology 'deprecated'. For example, the 1.5 section often says > "is  deprecated" or "has been deprecated", when what they mean is "will >

Re: deprecation vs removal

2011-10-03 Thread Russell Keith-Magee
On Sun, Oct 2, 2011 at 12:10 AM, Luke Plant wrote: > Hi all, > > The Django deprecation timeline [1] is very inconsistent in its usage of > the terminology 'deprecated'. For example, the 1.5 section often says > "is  deprecated" or "has been deprecated", when what they mean

Re: deprecation vs removal

2011-10-03 Thread Stephen Burrows
As a native speaker, I've never had a problem with the words or phrases being discussed here. Sure, it's jargon. It might be more accessible if we used other language. I don't really care one way or the other. But it's jargon. The fact that Miriam-Webster doesn't know what the word actually means

Re: deprecation vs removal

2011-10-02 Thread Łukasz Rekucki
2011/10/2 Alexander Schepanovski :> Then when I upgrade django I'll just upgrade it and fix> any wrong calls, imports, monkey patches etc. Proper upgrading docs,> which you write anyway, will make it into a couple of days. The way it> is done now still requires that two days

Re: deprecation vs removal

2011-10-02 Thread Ryan McIntosh
770-3682 r...@peaceworks.ca - Original Message - From: "Alexander Schepanovski" <suor@gmail.com> To: "Django developers" <django-developers@googlegroups.com> Sent: Sunday, October 2, 2011 12:48:38 AM GMT -06:00 US/Canada Central Subject: Re: deprecat

Re: deprecation vs removal

2011-10-01 Thread Alexander Schepanovski
> It allows you the luxury of taking the time, > and encourages you to upgrade even if you don't have time to make > application changes. It doesn't really saves time for me. But maybe I'm an uncommon case. Some of things I do with django are pretty tied up to its internals. But even a common

Re: deprecation vs removal

2011-10-01 Thread Paul McMillan
> what is not cause they have separate deprecation policies. It also > encourages me to slack at upgrading and use something deprecated for a > while longer. Yes, but in the meantime you're using the newer, better supported, and often more-secure code. It allows you the luxury of taking the time,

Re: deprecation vs removal

2011-10-01 Thread Alexander Schepanovski
For me, as an extensive django user, a whole deprecation thing is somewhat useless and confusing. I'd prefer deprecated elements were just removed. Then when I upgrade django I'll just upgrade it and fix any wrong calls, imports, monkey patches etc. Proper upgrading docs, which you write anyway,

Re: deprecation vs removal

2011-10-01 Thread Paul McMillan
I agree with your analysis of the word, but also agree that the terminology is likely to confuse people for a while. PendingDeprecation is a rather unfortunate construction. If we can pull through the phase where people are confused, our terminology will be more precise for the change. +1 from me.

deprecation vs removal

2011-10-01 Thread Luke Plant
Hi all, The Django deprecation timeline [1] is very inconsistent in its usage of the terminology 'deprecated'. For example, the 1.5 section often says "is deprecated" or "has been deprecated", when what they mean is "will be removed", which is what the other sections generally tend to say. Some