Deprecations should have a version horizon, not a date horizon

[deivid-rodriguez]

My current problem is that I think our deprecations should have a version horizon like: "this thing will be removed in rubygems 4", instead of a date horizon like: "this thing will be removed on or after december 2020".

Does anyone know what's the rationale of setting a specific date instead of a future version? Setting a date seems very arbitrary to me.

[bronzdoc]

I think that would be better.

[rubyFeedback]

It may be due to xmas release of stable ruby, which rubygems might (or might not) want to sync on (but is at the least partially necessary to sync, since otherwise you have the ruby release cycle become at odds with rubygems, which would be bad for the larger ecosystem IMO)..

I would actually consider to include both. Something like:

"This code part xyz will be removed in rubygems 4" (or 4.0).
"The expected time for this to happen may be after December 2020,
but the exact date may vary."

Or something like this.

That way, people will know at which specific version it will be changed;
AND they would at least know some rough estimate as to when this may
happen - the latter may be useful for people who are not as much aware
for how ruby works, such as for newcomers or something.

The above is just a suggestion; the message could be more terse of course).

[duckinator]

I also think specifying the version may be more useful than dates.

Related but distinct from this, I just opened #3022 ("Large number of methods where planned deprecation dates are 1+ year ago").

[Schwad]

Specifying the date is useful for those who rely on the dependency, when forecasting timelines when they ought to resolve to a newer version.

I understand the sentiments here, but practically dates do have use to teams as well. I don't see switching from it as harmful however.

[bronzdoc]

@Schwad The problem with dates is that for whatever reason we cannot remove/deprecate the thing being deprecated at the date we initially specified, we are stuck with that date in the codebase until we decide is appropriate to remove it entirely. Like is happening now, i.e #3022

Right now Gem::Util.gunzip will trigger a deprecation warning that it would be removed at 12/2018 to give a concrete example.

We want to avoid that.

[bronzdoc]

Closed with #3414