Wiki

Case Status Kiln
Log In

Wiki

 
Scenario
  • RSS Feed

Last modified on 24/09/2013 12:26 a.m. by User.

Tags:

Scenario

 

The idea is to let the deprecated method in the current version so that people can migrate without having to load the package

 
Note that this is basically what we are doing even if this is not that rigorous.
 

In 1.0

  • we are in 1.0
  • we deprecate methods with a tag 1.0
  • deprecated methods are published in one package deprecated10
 

In 1.1 alpha

  • we deprecate methods with a tag 1.1
  • deprecated methods 1.1 are published in one package deprecated11
  • 1.1 is shipped with deprecated10 and 11
 

In 1.2 alpha

  • we unload deprecate10
  • we deprecate methods with a tag 1.2
  • deprecated methods 1.1 are published in one package deprecated11
  • 1.2 is shipped with deprecated1.1 and deprecated1.2
 
What would be good is to have a refactoring to automatically do the following:
 
  • rewrite xxx into xxx + deprecation annotation as shown below
  • rewrite all the sender to call the new method
  • change the method category to be DeprecateXX
 
1:
2:
3:
4:
asSortedArray
        self deprecated: 'Use asArray sort' on: '01 April 2010' in: 'Pharo1.1'.
        self isSorted ifTrue: [^ self asArray].
        ^ super asSortedArray
 

Comments

  1. stephan@stack.nl said:

In addition, we need a process/tool that scans squeaksource for the (suspected) use of deprecated methods. (Jan 3, 2011)