[squeak-dev] Deprecation policy
Locked
[squeak-dev] Deprecation policy
 
|
I would like to suggest that we develop a formal deprecation policy. It
could be as simple as deprecate in one release, remove in the next. I just think we need to be consistent about it and remove no individual methods without following it. How this relates to the idea of repackaging and removing whole categories of classes, I'm not so sure. Ken |
signature.asc (196 bytes)
Re: [squeak-dev] Deprecation policy
|
|
On Fri, 2009-07-03 at 16:41 -0500, Ken Causey wrote:
> I would like to suggest that we develop a formal deprecation policy. It > could be as simple as deprecate in one release, remove in the next. I > just think we need to be consistent about it and remove no individual > methods without following it. How this relates to the idea of > repackaging and removing whole categories of classes, I'm not so sure. > > Ken Jecel (on IRC) has reminded me that this is nothing new and is basically the policy that was used starting with 3.8. Edgar: Did you or Ralph remove any methods marked as deprecated prior to 3.10? I'm thinking not since there is a package 39Deprecated still in 3.10.2 and a number of other callers of #deprecated: . In addition to an overall policy we need a policy on keeping track of deprecations. Perhaps it should be standard that the deprecation error message clearly states the release in which the deprecation occurred. Or we could continue to follow the example of 3.9. Ken |
Re: [squeak-dev] Deprecation policy
|
|
In reply to this post by Ken Causey-3
Hi Ken,
On Fri, Jul 3, 2009 at 2:41 PM, Ken Causey <[hidden email]> wrote: I would like to suggest that we develop a formal deprecation policy. It It would be good to add a date, version and selector Deprecation as in self deprecated: 'use Foo>>mumble' on: '2009/6/3' in: 'Croquet1.0beta'
Move the preference check into Deprecation defaultAction. This would allow logging to collect a set of selectors used in a particular run, e.g. deprecations := Deprecation deprecationsWhile: [self runMyTests]
as in the attached
|
Re: [squeak-dev] Deprecation policy
|
|
Re: [squeak-dev] Deprecation policy
|
|
In reply to this post by Eliot Miranda-2
Self-correction: Deprecation policy dates by at least to 3.6 as
evidenced by an email from Doug Way in 2004 and a swiki page he created http://wiki.squeak.org/squeak/3940 I'm currently leaning towards Eliot's solution and am evaluating it. If anyone has any concerns or preferences I would like to hear them. Oh, and yes, I realize that I asked about deprecation and barely 24 hours later removed entire classes without any deprecation. Evaluating this now is part of my intention to address that. Ken On Fri, 2009-07-03 at 19:25 -0700, Eliot Miranda wrote: > Hi Ken, > > On Fri, Jul 3, 2009 at 2:41 PM, Ken Causey <[hidden email]> wrote: > I would like to suggest that we develop a formal deprecation > policy. It > could be as simple as deprecate in one release, remove in the > next. I > just think we need to be consistent about it and remove no > individual > methods without following it. How this relates to the idea of > repackaging and removing whole categories of classes, I'm not > so sure. > > > It would be good to add a date, version and selector Deprecation as in > > > self deprecated: 'use Foo>>mumble' on: '2009/6/3' in: > 'Croquet1.0beta' > > > Move the preference check into Deprecation defaultAction. This would > allow logging to collect a set of selectors used in a particular run, > e.g. > deprecations := Deprecation deprecationsWhile: [self runMyTests] > > > as in the attached |
| Free forum by Nabble | Edit this page |