When to deprecate

[cmr]

When do we deprecate and how long do we deprecate for?

https://github.com/rust-lang/rust/pull/15514 removes the advance method from Iterator, which has been a long time coming, but should we deprecate it first to aid the transition for people who never actually upgraded to external iterators. I imagine we’ll have to revisit this question as we near 1.0.

[huon]

It’s not much effort to deprecate, and someone who doesn’t know the history won’t know it’s just a hold over from times long passed. #[deprecated] all the things!

(The guidelines about how long to deprecate has been vague on purpose… kinda just “a month or so”.)

[erickt]

There’s a short term, medium term, and long term answer to that. Since we just cut a release and I’ve been having to touch my code a lot due to other changes, I’d be fine if we rip the band-aid off now and remove all the deprecated features now. After we do that, it’d be nice to put a timestamp on the #[deprecated(date="2014-01-01")] and we can get a notification after a month or so it’s not sitting around forever. For 1.0, we could add #[deprecated(version="0.11")] and warn if it’s in when we bump the version number.

[bjz]

I know that quite a few people were hit hard by the overnight to_str->to_string change. As somebody who maintains a number of ‘foundational’ libraries it took me a couple of days to get everything back in order (things can sometimes take time to sync with Travis). I imagine it would have taken even longer for folks downstream.

I don’t mind updating usages of deprecated functions, and we have greatly appreciated the current move towards having a ‘grace period’ to get our houses in order. No matter how trivial the change, deprecation is of great benefit to those downstream.

[cmr]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.