On 31 December 2010 19:47, Levente Uzonyi <[email protected]> wrote: > On Fri, 31 Dec 2010, Igor Stasenko wrote: > >> 2010/12/31 Levente Uzonyi <[email protected]>: >>> >>> On Fri, 31 Dec 2010, Igor Stasenko wrote: >>> >>>> ahahaa.. you guys are killing me.. >>>> You are taking things too serious. >>>> Yeah.. i would be gladly hear from Levente, what is 'the proper >>>> deprecation policy'. >>>> But since nobody described it, we are doomed to use one, invented before >>>> :) >>> >>> I described my ideas here, so I won't repeat it. But I can tell you that >>> removing a method which wasn't deprecated at all is _not_ a proper >>> deprecation policy. >>> >> can you give a pointer, where i can read about it? > > You can search this mailing list. But to make it a bit easier, it's > basically the same as what it's intended to be: > - deprecate all non-private methods that are to be removed (some private > methods should also be deprecated) > - keep the deprecated methods for at least one new release > - calculate the deprecation dates from the method timestamps > Forgive me my ignorance. I know that Pharo using a deprecation policy, but i didn't paid much attention to details, and probably missed some key messages where policy was discussed. I knew only that people agreed to not remove methods immediately and that deprecation warning should stay at least single release cycle.
-- Best regards, Igor Stasenko AKA sig.
