Samuel Tardieu @


Rust attribute to force deprecated item removal at a specified version

This crate introduces a new deprecate_until attribute which helps crate authors not to remove to delete obsolete items when some version is reached. When the specified semver condition is verified, the crate will not compile anymore and hopefully this will be caught by the CI or by cargo install before the release actually happens.


The deprecate_until attribute supports the same arguments as deprecate, i.e., note and since. It also requires a remove argument, which is a semver requirement expression in a string.


The following code

use deprecate_until::deprecate_until;

#[deprecate_until(remove = ">= 4.x", note = "use `some_new_function` instead")]
fn old_function() {

will give a warning when version 3.8 of the crate is used in a project:

warning: use of deprecated function `old_function`: use `some_new_function` instead
         (removal scheduled for version >= 4.x)
4 | fn old_function() {
  |    ^^^^^^^^^^^^

It will also cause a compilation error in version 4.0.0 of the crate if you forgot to remove it:

error: version `4.0.0` matches `>= 4.x`, item should be removed
3 | #[deprecate_until(remove = ">= 4.x", note = "use `some_new_function` instead")]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Using deprecate-until

In order to use deprecate-until, you can add it to your Cargo.toml as a dependency
deprecate-until = "0.1"
The package documentation is available online.

Getting deprecate-until

Published version (0.1)

You can access the crate from and the Documentation.

Development version

You can get the current development version of deprecate-until using git:
git clone
This will create a deprecate-until directory in which you will be able to record your own changes. You can also browse the deprecate-until repository on GitHub.

Contributing to deprecate-until

Reporting bugs and asking for features

If you find a bug or have an idea for a new feature, you might consider adding a new issue. The more precise you will be in your description, the more useful it will be.

Submitting patches

Patches are gladly accepted from their original author. Along with any patches, please state that the patch is your original work and that you license the work to the deprecate-until project under a license compatible with the current one (Apache 2.0 license / MIT license).

To propose a patch, you may fork the deprecate-until repository on GitHub, and issue a pull request. You may also send patches and pull requests by email.