I agree that we have too many uses of code deprecated in our own code base. I also agree with the idea that we should not introduce new usages of deprecated classes. So if someone is modifying a class that uses deprecated classes, should the deprecations be refactored out or is it OK to leave them? Seems hard to make firm “rules” (or should we call them guidelines?). Each case needs to be looked at with respect to code complexity, how extensive is the original code change and are the deprecated uses in the area of change, and will removing the deprecations require API changes to inject new dependencies to support removing the deprecations.
We do have the guideline that deprecated classes can’t be removed until at least the major release after the release in which the class was deprecated. So currently we’re looking at Geode 2.0 to possibly remove deprecated classes. Now to get where it would be OK to remove a deprecated class in 2.0.0, then it seems to me that the initiative should be to remove all current uses of the class in the core product and in test code prior to when the decision is made to work toward a 2.0.0 release. In other words, do it sooner and avoid the rush to do it all just before the release. > On Jan 2, 2019, at 11:38 AM, Peter Tran <pt...@pivotal.io> wrote: > > Hello Geode Dev, > > As a new contributor reviewing PRs I've learnt that it's acceptable to make > a PR that continues to use deprecated classes but not okay to introduce the > usage of a deprecated class. > > I wonder if there should be a systematic way to remove the usage of > deprecated classes. I'm concerned over time the code base will accumulate > more and more deprecated classes unless there is a system in place in which > they are removed. > > Has there been any initiatives in the past to do this? Are having a lot of > deprecated classes still in use a low risk thing? > > Thanks, > > Peter > -- > Peter Tran > PCF Toronto
