So what, in practice, does "deprecated" mean?

[hazel]

This is a spin-off from another thread, but I think it's worth one of its own. Miven and I seem to disagree on the meaning of the word "deprecated".

Now I am rather pedantic because I'm a border-line autist; I assume that if functions are deprecated, it's for some good reason. Miven says that as long as a function works on your system, it doesn't matter whether it's deprecated or not. Just turn off the -Wall flag and you won't see the warnings any more.

What do other people think? Does it matter if something is deprecated? If not, why not?

[elija]

Deprecated tends to mean that "this thing is still available now but don't count on it being maintained, fixed or even still here in the next version" In practise however, in more widely used libraries and frameworks deprecated items tend to hang around for quite a while as removing them could break a lot of existing software.

It is usually recommended that when writing new software that you don't use them and if you follow principles like continuous refactoring then you should consider replacing existing uses as part of that process.

[Lazydog]

I take it to mean that the object it is referring to has been superseded/replace by something newer/improved.

[MikeTbob]

I think you guys got it right. From Websters online dictionary:

deprecated - Said of a program or feature that is considered obsolescent and in the process of being phased out, usually in favour of a specified replacement. Deprecated features can, unfortunately, linger on for many years. This term appears with distressing frequency in standards documents when the committees writing the documents realise that large amounts of extant (and presumably happily working) code depend on the feature(s) that have passed out of favour.

See also dusty deck.

[Irithori]

It depends on
- where the systems/apps are installed (strictly internal vs online)
- the available resources (Devs, QA, Ops, Management, Hardware, Testing environments, etc)
- guidelines (Security, Best Practice setup, internal guidelines, etc)
- need for support (Think: SLAs with external companies)
- need for active development
- how many and what type of users are expected
- the importance and worth of the data managed by said systems/apps


As an example:
Say, there is need for a fileserver in a private home network.
- The expected users are: One person. The owner of that network.
- The owner decides: an encypted filesystem is a must have.
- Still there is need for a stable tool
- The fileserver shall just do its job. No fancy plugins or feature requests are expected by the owner. (aka: support and active development are not that important)

In this case, freenas 7 -although deprecated- would be a better choice than freenas 8.
FreeNAS 8 - Storage For Open Source - Version Comparison


If the parameters are slightly changed:
The fileserver is meant for a professional environment, not any longer for one person:
Then there is no way around the current and supported system, encryption be damned.
Support, active development and SLAs are just too important.
At least, this is my point of view if I would be responsible for this fileserver.


Another and real life example from the perspective of a sysadmin for a larger online platform:
Online business *requires* your company to stay up to date for both security and feature reasons.
There is absolutely no way around that, or your service will get exploited/hacked or become slow/unattractive over time.

So, if your php/java/<whatever> complains about the use of deprecated functions/API, then this is an ActionItem for all involved parties.
Because on the next major update these deprecated functions may no longer be available, which would leave your application/tool restricted to an old platform.
And as I just explained: This is not an option in the long run for online business.

Now, in a perfect world a new environment would be deployed by Ops in a TestLab as soon as it is available,
the devs would happily update all their apps,
because management gave them time and resources to do so,
and qa would also in the meantime adjust their tooling.

In reality (at least in my experience) this needs a bit of meetings, persuasion and leverage.
So the issues for a migration might queue up a bit, but eventually it *will* happen.

That is also why e.g. RedHat is on the right track by freezing their major release to specific tool versions/features and supporting them by still providing security patches and even backports.
This gives clear deadlines for the teams of a company (RH support until <month><year>), while the new rhel is already available to setup, develop and test an environment for your apps with.


TL;DR: It depends on the usecase, whether or not "deprecated" is important.

[Miven]

Thank you Hazel, for starting this thread. You made me laugh.

You're a neatnik, and I'm not.

I go with whatever works, and I fail to care whether it is:

deprecated,
obsolete,
crude,
rude,
undefined (I'll #define it myself),
defined (I'll #undef it, or comment it out, or rewrite it completely )

You should see the command line option parser I'm working on at this very time. I know it's already been done (coreutils). I like mine better. My hex editor doesn't even take command line options. I'm doing it as a programming exercise. Feed it garbage, and it turns out cleverness. I make broken things work. That is what I do. And occasionally I get paid very well for it.

I wish it was more often Thank you, I'm still chuckling.

Always remember, code is just a form of poetry.

Peace and Cheer.

[oz]

So what, in practice, does "deprecated" mean?

Wikipedia.org has their own interpretation of the term "deprecation" for computer software usage:

https://en.wikipedia.org/wiki/Deprecation

Of course, I don't always believe or trust in the accuracy of everything that is written there.