About deprecated methods

Doug Way dway at riskmetrics.com
Fri Sep 12 22:38:03 UTC 2003


Joshua 'Schwa' Gargus wrote:

>On Fri, Sep 12, 2003 at 12:48:06AM -0400, Doug Way wrote:
>  
>
>>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.
>>    
>>
>
>We could just make it a convention to add a comment stating when the
>method was deprecated; the comment could be could be put right above
>the deprecation call.
>  
>

True, although we'd still have to worry about enforcing that... I'd 
guess sometimes it would be forgotten.  Keep a list somewhere after each 
release would probably end up being more reliable.

>>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.  
>>    
>>
>
>You're saying methods deprecated in 3.6 would be removed when 3.7 becomes
>final (or gamma)?  Ah, that's different from what I remember you saying...
>I thought you said deprecated methods would be removed at the beginning
>of the 3.7 cycle.
>

Actually you were right before, I was/am going to remove the deprecated 
methods at the beginning of the 3.7alpha cycle. (which would be very soon)

I only mentioned the time between the final versions above because many 
people will not be continuously updating their packages/applications 
during the alpha cycle, they'll only update them from one final release 
to the next. (say, Comanche for example)  So for these people, the 
period of time that matters is in between the x.y and x.y+1 final versions.

The time from deprecation to removal could be as short as ~2 months for 
people continuously following the alpha stream, but I would argue that 
people who follow the alpha stream are "test pilots" who shouldn't 
expect as much stability.

>>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.  ...
>>
>
>That sounds good to me.
>
>  
>
>>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.
>>    
>>
>
>Or we would just deprecate the old method ;-)
>  
>

True! ;-)

- Doug




More information about the Squeak-dev mailing list