Hacker News new | past | comments | ask | show | jobs | submit login

I will continue my attempt to rescue the word “deprecate” from destruction.

> Git.io deprecation

> As notified in January, we shared our plans to deprecate the service.

This is not deprecation. This is discontinuation.

Deprecation is when you say “we recommend not using this, but it’s still working for now”; at time of deprecation, a schedule of when it will cease to work may be provided, or it could be that it will continue to work indefinitely.

The announcement in January was the deprecation. What they’re doing now is the final discontinuation.




If you want to be pedantic you need to also be fully correct.

This announcement in itself is a deprecation, just like the last one, that additionally announces a future discontinuation.

There is no requirement a deprecated service still works.

If something is half broken you can deprecate it for those relying on the half-broken mess and eventually discontinue it (which is what Github is doing)


Take both notices together and you can see that they’re clearly using the wrong sense of the word deprecate. From the January notice:

> Existing URLs will continue to be accessible, but we encourage using one of the many URL shortening services that are available, instead of git.io, as we will be deprecating the tool in the future.

Semantically, that was clearly a deprecation of the service: it keeps working, but they discourage its use as it will be discontinued in the future. (It was also notice of shutdown of the write parts of the service.)

It is not reasonable to consider today’s notice to be a deprecation (interpreting that as a change in status).

> There is no requirement a deprecated service still works.

This is flatly wrong. The agreed meaning of the word “deprecate” requires that it still works. See https://en.wikipedia.org/wiki/Deprecation for a good overview of the term’s proper usage and accepted meaning.


> This is flatly wrong.

It's not flatly wrong, you're just stuck on a tautological use of the word "work"... after all how do you deprecate something that doesn't exist?

I used the example below: you can stub out a method with a print statement that says "don't use this" and still deprecate it.

The function still "works" in the most literal sense... it just doesn't do any useful work. It doesn't work.

> Semantically, that was clearly a deprecation of the service: it keeps working, but they discourage its use as it will be discontinued in the future.

You can't call the original a deprecation and say this one is not. Git.io still works (in reduced but extremely meaningful capacity... git.io links all still work) and they're recommending alternatives.

Your other hang up is said they will deprecate something during a depreciation.

That's perfectly allowed if you're actually going to be this pedantic? I will run while I'm running doesn't make it a false statement.

Also to be clear I'd just rather people not be as pedantic as the grandfather comment. Sometimes it's good to hold up a mirror to that end.


Your quibbles are altogether unreasonable.

> you can stub out a method with a print statement that says "don't use this" and still deprecate it.

That’s not deprecation. That’s breaking the method.

To define “works” somewhat more specifically: deprecation means that functionality is not materially altered from how it was before the deprecation. (You might devise some way of notifying users—e.g. DeprecationWarning in Python, #[deprecated] in Rust—but this does not materially alter functionality.)

The January notice was a deprecation (even if they mislabelled it). This notice is not a deprecation, because the service was already deprecated. This notice defines a sunset timeline, but does not alter the parameters of the deprecation.


> That’s not deprecation. That’s breaking the method.

It's both. You can even break a feature and deprecate it for that reason. Deprecation comes down to communication.

> deprecation means that functionality is not materially altered from how it was before the deprecation.

No it doesn't. Maybe you really want it to, but it doesn't.

> This notice is not a deprecation, because the service was already deprecated.

That's not how that works... you can deprecate something and deprecate it again. Each notice is the deprecation if you don't realize this I don't know what you're still going on about...


> It's both. You can even break a feature and deprecate it for that reason. Deprecation comes down to communication.

To deprecate something is to recommend against it's use, but it must still be possible to use it without heeding the depreciation.

Removing all the functionality of something and replacing it with a debug message is not depreciation, it's discontinuation.

>> deprecation means that functionality is not materially altered from how it was before the deprecation.

> No it doesn't. Maybe you really want it to, but it doesn't.

Do you accept that your view of deprecation is not compatible with the definition in say, Wikipedia?


You're very wrong about how deprecating an API works.


Since the service is already read-only, you don't have the option of using it against the recommendation, and so no this is not merely a deprecation.


Like I said, the feature can be half-broken during deprecation.

Read-only still lets you use it: http://git.io/iEPt8g

The feature can be a stub that prints "no pls" and you're still free to mark it as deprecated (that's more common than one might expect because ABIs are a thing)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: