deprecate-until
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.
Usage
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.
Example
The following code
use deprecate_until::deprecate_until;
#[deprecate_until(remove = ">= 4.x", note = "use `some_new_function` instead")]
fn old_function() {
todo!()
}
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 yourCargo.toml
as a dependency
[dependencies]
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 .Development version
You can get the current development version of deprecate-until using git:git clone https://github.com/samueltardieu/deprecate-until.git
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.