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
mainbranch is up to date:
- Checkout a new branch with the release version name:
- Update the
versionfield inCargo.tomlto reflect the desired new version of the crate, following semantic versioning best practices. - Update the
CHANGELOG.mdsuch 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
mainbranch again:
- Run
cargo publish --dry-runto perform a dry run, ensuring that your publishing process will proceed as expected. - Run
cargo publishto publish the new version of this crate to crates.io.
cargo release workflow:
- Ensure the
mainbranch 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 releasedryrun output in the PR body.
;
## [Unreleased] - ReleaseDate
### Changed
- Once your PR is approved, run
cargo release <LEVEL> -v --executeand select yes (y) to confirm that you would like to publish to crates.io. This will automatically update theversionfield inCargo.tomland replace the## [Unreleased] - ReleaseDateheader inCHANGELOG.mdwith 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
mainand the released crate version are in parity.
License
MIT