First create something that works (to provide business value).
Then something that’s beautiful (to lower maintenance costs).
Finally works on performance (to avoid wasting time on premature optimizations).
This project more or less follows Semantic Versioning.
Which boils down to the following rules of thumb regarding stability:
Are bug-fix only. These releases must not break anything and keep backward-compatibility with
Includes any non-bugfix changes. These releases must be backward-compatible with any
0.n.*version but are allowed to drop compatibility with the
0.(n-1).*series and below.
Make no promises about backwards-compability. Any API change requires a new major release.
This step is required for all the other sections from this page.
Check out latest development branch:
$ git clone firstname.lastname@example.org:kdeldycke/mail-deduplicate.git $ cd ./mail-deduplicate $ git checkout main
Install package in editable mode with all development dependencies:
$ python3 -m pip install poetry $ poetry install
Now you’re ready to hack and abuse git!
mdedup development version#
After the steps above, you are free to play with the bleeding edge version of
$ poetry run mdedup --version mdedup, version 7.0.0-dev (...)
Run unit-tests with:
$ poetry run pytest
The documentation you’re currently reading can be built locally with Sphinx:
$ poetry run sphinx-build -b html ./docs ./docs/html
The generation of API documentation is covered by a dedicated workflow.
Project screenshots found in the documentation and the
readme.md file needs
to be refreshed by hand once in a while.
To produce clean and fancy terminals screenshots, use either:
Before a release, the maintainers will review and rewrite the changelog to make it clean and readable. Inspiration can be drawn from the keep a changelog manifesto.
Changes can be inspected by using the comparison URL between the last tagged
version and the
main branch. This link is available at the top of the
All there’s left to do is to:
check the open draft prepare-release PR and its changes,
Ready for reviewbutton,
Rebase and mergebutton,
let the workflows tag the release and set back the
mainbranch into a development state.
Versions are bumped to their next
patch revision during the release process
above by the
At any point during development, you can bump the version by merging either the
major-version-increment branch, each available
in their own PR.