The crate no longer depends on failure.
The error now implements std::error::Error.
Note that this is a BREAKING CHANGE, because failure::Context was leaked to the public API (via From<Context<ErrorKind>> impl.
Whilst this introduces a breaking change (which essentially means moving to v2.0.0) I suggest making distinct error types for lock() and try_lock() functions as it is done for std::sync::Mutex::lock and std::sync::Mutex::try_lock, besides that it would be nice to have an ability to handle unlock error, this would just mean having a consuming unlock(self) method which returns a Result.
@yoshuawuyts I see this repo hasn't seen enough activity lately, but this is the crate people see one of the first when googling for file locks in Rust. If you feel you don't have enough time/motivation for maintaining it I suggest my help with that.
Motivation and Context
Closes #4
Types of changes
[x] Breaking change (fix or feature that would cause existing functionality to change)
Description
The crate no longer depends on failure. The error now implements
std::error::Error
. Note that this is a BREAKING CHANGE, becausefailure::Context
was leaked to the public API (viaFrom<Context<ErrorKind>>
impl. Whilst this introduces a breaking change (which essentially means moving tov2.0.0
) I suggest making distinct error types forlock()
andtry_lock()
functions as it is done forstd::sync::Mutex::lock
andstd::sync::Mutex::try_lock
, besides that it would be nice to have an ability to handle unlock error, this would just mean having a consumingunlock(self)
method which returns aResult
.@yoshuawuyts I see this repo hasn't seen enough activity lately, but this is the crate people see one of the first when googling for file locks in Rust. If you feel you don't have enough time/motivation for maintaining it I suggest my help with that.
Motivation and Context
Closes #4
Types of changes