Handling End-of-life of a version

[briansmith]

Let’s say I publish create Foo 1.0.0 on crates.io. Then, after some time, I publish 2.0.0, incompatible with Foo 1.0.0, and I don’t want to, or can’t, support 1.0.0 any more. Then, let’s say there is a critical security bug in Foo 1.0.0 so nobody should use it.

crates.io supports “yanking” a package, which handles the case for new crates that try to depend on Foo 1.0.0. But, how can I stop existing crates from (silently) continuing to use the dangerously-non-secure Foo 1.0.0? I would like to be able to “yank” in such a way that, at a minimum, downstream users are warned during the build of the potential problem.

[killercup]

IIRC, npm does it this way: You publish Foo 1.0.1 which adds a deprecation warning on install/build. I’m not sure Cargo allows packages to print warnings, though. (Maybe printing to stderr in a build.rs?)

[seanmonstar]

Actually, npm allows you to do npm deprecate Foo@1.0.0 "message", which will output a warning with the text from message when that version is installed.

[sfackler]

I believe Cargo will warn if you depend on a yanked version of a crate.

[DenisKolodin]

crates.io supports “yanking” a package, which handles the case for new crates that try to depend on Foo 1.0.0. But, how can I stop existing crates from (silently) continuing to use the dangerously-non-secure Foo 1.0.0? I would like to be able to “yank” in such a way that, at a minimum, downstream users are warned during the build of the potential problem.

Cargo discards yanked dependency on update. But I think your case is a problem who uses your library. If you made a mistake yank it and put update. Even some important libs do it.

It’s great that library still exists: for developers it means possibility to make changes for future version. If you drop library completely somebody will lose chance to build own project.

[system]

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