On Thursday, September 11, 2003, at 10:45 AM, Joshua 'Schwa' Gargus 
wrote:

> Hi Stef,
>
> I've had the same thought.  I can't think of a downside to waiting two
> versions before removing deprecated methods.

The one downside to doing this is that keeping track of which methods 
will be deprecated when becomes more complicated.  I guess we'd just 
need to keep a list somewhere of which methods had been deprecated two 
versions ago versus one version ago.  Or somehow store that information 
in the method itself.

Given that I'd slightly prefer to just wait one version.  Most other 
languages (e.g. Java) wait just one version for deprecated methods to 
be removed.  (I think most do, anyway.)

We could wait two versions if others feel strongly about it, though.

> After all, we haven't
> been deprecating methods at all for years, and the world hasn't
> exploded.

That actually sounds like an argument to wait a shorter amount of time. 
  We haven't been deprecating methods at all for years, in other words 
waiting "zero" versions, so we could probably survive waiting one 
version rather than two. :-)

> On Thu, Sep 11, 2003 at 08:25:11AM +0200, ducasse wrote:
>>
>> I was thinking that we should let the deprecated methods over two
>> versions to let the people the time to update. Do you think that this
>> is silly? What is the period of time since 3.5?

The period of time between 3.5final and 3.6final will be 5 1/2 months, 
barring any major problems.  The time between 3.6 and 3.7 will probably 
be roughly the same.  So methods marked as deprecated in 3.6 would be 
gone in 3.7, 5-6 months later.  This seems like a reasonably long time 
to me.  Although I suppose my Java example above might not be so good, 
since there's usually a year or so between Java releases, e.g. 1.3 to 
1.4.... so maybe 5-6 months isn't so long.

Speaking of deprecated methods, someone mentioned awhile ago that they 
thought the deprecation method should be renamed from 
#deprecatedExplanation: to just #deprecated:.  I think this would be a 
good idea.  The deprecatedExplanation: method name seems too verbose 
for such an important method... verbosity is okay for the names of 
rarely used methods, but for more commonly used methods shorter is 
often better, for example #do: and not #doBlock:. :-)  Also in this 
case when seeing the #deprecated: method being used it's pretty obvious 
that the string being passed along is the explanation.

If we wanted to rename this method, the beginning of 3.7alpha would be 
a good time, especially if all of the senders are removed.

- Doug