async-memcache
async-memcache is an async memcached client implementation for Tokio.
Warning: This is a work in progress crate.
Testing
The default test suite does not require memcached
to be running. It will ignore tests that require memcached
to be running.
For the full test suite, you need to have memcached
installed and running.
&&
Benchmark
To run the benchmark, you need to have memcached
installed and running.
Examples
You can run the examples with cargo run --example <example-name>
. Examples require a running memcached
server.
TCP
Run a memcached server (with optional very verbose flag) that accepts a TCP connection and execute the basic examples:
Unix Domain Socket
Run a memcached server (with optional very verbose flag) that accepts a UDS connection and execute the UNIX examples:
Profiling
Install samply
with cargo install samply
.
Features
This crate only targets the ASCII protocol, as the binary protocol has been deprecated and is no longer actively being improved.
- TCP connection
- UDP connection
- UNIX domain socket connection
- Authentication
- TLS
Releasing a new version
Developers should keep a running log of changes being made with each PR in CHANGELOG.md
, under the [Unreleased] - ReleaseDate
header to ensure that accurate change records are kept as part of the release cycle.
To release a new version of this crate, you must be part of the Owners group listed on crates.io. If you are not part of this group and require a release that includes recently merged changes, please open an issue on Github.
When using the cargo-release
crate to release a new version, the version
field in Cargo.toml
will be bumped automatically according to the <LEVEL>
argument that has been provided. Additionally, CHANGELOG.md
will have version and date fields updated
automatically. See the cargo-release
documentation for more info on versioning and options.
cargo publish
workflow:
- Ensure the your
main
branch is up to date:
- Checkout a new branch with the release version name:
- Update the
version
field inCargo.toml
to reflect the desired new version of the crate, following semantic versioning best practices. - Update the
CHANGELOG.md
such that the latest changes are under a header with the new version & release date:
## [Unreleased] - ReleaseDate
### Added
- a cool new feature
### Changed
- something to be more optimized
Should be updated to:
## [Unreleased] - ReleaseDate
## [Major.Minor.Patch] - 20YY-MM-DD
### Added
- a cool new feature
### Changed
- something to be more optimized
- Push your changes to the remote, get approval and merge your PR
- Update your
main
branch again:
- Run
cargo publish --dry-run
to perform a dry run, ensuring that your publishing process will proceed as expected. - Run
cargo publish
to publish the new version of this crate to crates.io.
cargo release
workflow:
- Ensure the
main
branch is up to date:
- Checkout a new branch with the release version name:
- Open a PR on GitHub and fill out the PR template for a release. Provide the
cargo release
dryrun output in the PR body.
;
## [Unreleased] - ReleaseDate
### Changed
- Once your PR is approved, run
cargo release <LEVEL> -v --execute
and select yes (y
) to confirm that you would like to publish to crates.io. This will automatically update theversion
field inCargo.toml
and replace the## [Unreleased] - ReleaseDate
header inCHANGELOG.md
with the appropriate version and date automatically, and then publish the crate with those changes included. These changes will also be pushed to your remote branch. - Merge your PR so that
main
and the released crate version are in parity.
License
MIT