We welcome contributions to zLMDB! This guide explains how to get involved.
- GitHub Issues: Report bugs or request features at https://github.com/crossbario/zlmdb/issues
- GitHub Discussions: Ask questions and discuss at https://github.com/crossbario/zlmdb/discussions
When reporting issues, please include:
- Python version (
python --version) - zLMDB version (
python -c "import zlmdb; print(zlmdb.__version__)") - Operating system and version
- LMDB version if relevant
- Minimal code example reproducing the issue
- Full traceback if applicable
- Fork the repository on GitHub
- Create a feature branch from
master - Make your changes following the code style
- Add tests for new functionality
- Add a changelog entry to
docs/changelog.rstfor any user-visible change (kept in the PR so the branch is self-contained) - Run the test suite to ensure nothing is broken
- Submit a pull request referencing any related issues
git clone https://github.com/crossbario/zlmdb.git
cd zlmdb
pip install -e .[dev]# Run all tests
just test
# Run tests in specific venv
just test cpy312- Follow PEP 8
- Use meaningful variable and function names
- Add docstrings for public APIs
- Keep lines under 100 characters
This project uses CalVer with PEP 440 development
releases: YY.M.PATCH[.devN] — for example, 26.7.1 for a stable release and
26.7.1.dev1 while in development. Between releases the working tree always
carries a .devN suffix.
The version is stored in two files kept in sync — pyproject.toml and
src/zlmdb/_version.py — and managed with just:
just file-version— show the current version (from both files)just bump-dev— bump to the next dev version for the current month (YY.M.1.dev1)just bump-next 26.7.2.dev1— set a specific next dev versionjust prep-release— strip the.devNsuffix to cut a stable release
Git tags and releases are created by maintainers only.
By contributing to zLMDB, you agree that your contributions will be licensed under the MIT License.