Contributing to Lettuce

June 30, 2026 · View on GitHub

Lettuce is released under the MIT license. If you would like to contribute something, or simply want to hack on the code this document should help you get started.

Code of Conduct

This project adheres to the Contributor Covenant code of conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to lettuce-redis-client-users@googlegroups.com.

Using GitHub Issues

We use GitHub issues to track bugs and enhancements. If you have a general usage question please ask on Stack Overflow. The Lettuce team and the broader community monitor the lettuce tag.

If you are reporting a bug, please help to speed up problem diagnosis by providing as much information as possible. Ideally, that would include a small sample project that reproduces the problem.

Quickstart

For the impatient, if you want to submit a quick pull request:

  • Don't create a pull request upfront. Create a feature request ticket first, so we can discuss your idea. API changes require discussion, use cases, etc. Code comes later.
  • Pull request needs to be approved and merged by maintainers into the master branch.
  • Upon agreeing the feature is a good fit for Lettuce, please:
    • Make sure there is a ticket in GitHub issues.
    • Make sure you use the code formatters provided here and have them applied to your changes. Don’t submit any formatting related changes.
    • Make sure you submit test cases (unit or integration tests) that back your changes.
    • Try to reuse existing test sample code (domain classes). Try not to amend existing test cases but create new ones dedicated to the changes you’re making to the codebase. Try to test as locally as possible but potentially also add integration tests.

When submitting code, please make every effort to follow existing conventions and style in order to keep the code as readable as possible. Formatting changes create a lot of noise and reduce the likelyhood of merging the pull request. Formatting settings are provided for Eclipse in https://github.com/lettuce-io/lettuce-core/blob/main/formatting.xml

Bugreports

If you report a bug, please ensure to specify the following:

  • Use a concise subject.
  • Check GitHub issues whether someone else already filed a ticket. If not, then feel free to create another one.
  • Comments on closed tickets are typically a bad idea as there's little attention on closed tickets. Please create a new one.
  • Lettuce version (e.g. 3.2.Final).
  • Contextual information (what were you trying to do using Lettuce).
  • Simplest possible steps to reproduce:

Features

If you want to request a feature, please ensure to specify the following:

  • What do you want to achieve?
  • Contextual information (what were you trying to do using Lettuce).
  • Ideally, but not required: Describe your idea how you would implement it.

Questions

If you have a question, then check one of the following places first as GitHub issues are for bugs and feature requests. Typically, forums, chats, and GitHub discissions are the best place to ask your question as you can expect to get an answer faster there:

Checkout the docs

Communication

Building from Source

Lettuce source can be built from the command line using Maven on JDK 1.8 or above.

A plain build, running only the unit tests, needs no Redis:

	$ mvn clean test

Testing

Lettuce runs its integration tests against real Redis servers started in Docker. The full testing infrastructure — the test container, how environments are started, how tests discover their servers, where to place unit vs. integration tests, and how this maps to CI — is documented in docs/integration-testing.md.

Quick start:

	$ make start version=8.6   # bring up the Redis test environment for a given version
	$ make test                # run the full build including integration tests
	$ make stop                # tear the environment down

When adding tests, please follow the unit vs. integration conventions described in the guide: unit tests are named *UnitTests (no running server), integration tests are named *IntegrationTests.

Conventions

  • New public API must be annotated with @since and the version it was introduced with (e.g. @since 6.0, @since 5.3.2)
  • Add yourself to each file you touch as @author
  • Split feature/bugfix commits from polishing commits (see PR #1400 and its polishing commit)
  • Commit messages follow the convention of a summary along with the ticket number and optionally a description in the body:
<text> #<ticketnumber>

We now correctly …

Examples:

Merging a Pull Request

  • Does it build? Is there a test case and does the design follow how Lettuce is built?
  • Minor formatting issues can be sorted out during the merge, for larger formatting issues (e.g. PR contains at least one reformatted file) we need to ask the contributor to fix it.
  • Squash multiple commits into a single one, except if the commits are well structured (e.g. commit introducing a feature/fixing a bug plus a commit that polishes up code)
  • Edit original commit message if necessary to reflect the ticket number. Add Original pull request: #<PR> to all commits belonging to the PR to keep changes together.