Based upon definitions I have read of the term deprecation, I get a general sense that deprecation is usually reserved for moving on to other methods/classes for good for reasons such as (and I borrow from Wikipedia):

  • The feature has been replaced by a more powerful alternative feature.
  • The feature contains a design flaw—frequently a security flaw—and so should be avoided, but existing code depends upon it.
  • The feature is considered extraneous, and will be removed in the future in order to simplify the system as a whole.
  • A future version of the software will make major structural changes, making it impossible (or impractical) to support older features.
  • Standardization or increased consistency in naming.
  • A feature that once was only available independently is now combined with its co-feature.

Is it proper to deprecate a method/class if there is a possibility that future decisions made in later versions of the code might require reinstatement of the deprecated functionality? That is, is it proper to undeprecate? Perhaps if not, what is the correct way to deal with this section of code?

In the context I am talking about, the deliverable is really a subsystem which is included in other projects. Therefore, the possible exposure is between development teams. However, some of the deprecated classes for instance would not be classes that would normally be directly instantiated by other projects. They could, but it generally does not fit into their use cases. An example that comes to mind is Stanford CoreNLP where just because a class or a method is accessible does not mean it is something that you should be using.

  • 1
    the deprecation implicitly define some/all the context described above. You have to tell to the clients why it's has been deprecated and the workaround/solution. Don't mark something as deprecated if it is not.
    – linuxunil
    Dec 15, 2016 at 16:45
  • "just because a class or a method is accessible does not mean it is something that you should be using". So why it is accessible in the first place?
    – linuxunil
    Dec 15, 2016 at 17:27
  • @linuxunil The purpose of this question was really to ask for best practice, not for my particular situation. For me, an example is an annotator class. Usually, the other programs will run a suite of annotators together, but they could need an individual annotator. It is possible.
    – demongolem
    Dec 15, 2016 at 17:32
  • I see your point. Let's stick to the question then. =D
    – linuxunil
    Dec 15, 2016 at 17:36

1 Answer 1


No, it is not proper. Deprecation should be a permanent operation. The term is usually used in regards to a public API, where changes to the API could cause turmoil if not managed carefully. In such a case, releases are gradual, preceded by betas, and deprecation is permanent.

What you describe sounds more like guidelines, or potentially poor API design. Well designed API's rarely need any deprecation. In your case specifically, it sounds as if the API may need to be split into multiple libraries, as a single one is not appropriate for all users.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.