Development¶
Philosophy¶
- First create something that work (to provide business value).
- Then something that’s beautiful (to lower maintenance costs).
- Finally works on performance (to avoid wasting time on premature optimizations).
Stability policy¶
This project follows Semantic Versioning.
Which boils down to the following rules of thumb regarding stability:
- Patch releases (
0.x.n
→0.x.(n+1)
upgrades) are bug-fix only. These releases must not break anything and keeps backward-compatibility with0.x.*
and0.(x-1).*
series. - Minor releases (
0.n.*
→0.(n+1).0
upgrades) includes any non-bugfix changes. These releases must be backward-compatible with any0.n.*
version but are allowed to drop compatibility with the0.(n-1).*
series and below. - Major releases (
n.*.*
→(n+1).0.0
upgrades) are not planned yet, unless we introduce huge changes to the project.
Setup a development environment¶
Check out latest development branch:
$ git clone git@github.com:kdeldycke/meta-package-manager.git
$ cd ./meta-package-manager
$ git checkout develop
Install package in editable mode with all development dependencies:
$ pip install -e .[develop]
Now you’re ready to hack and abuse git!
Coding style¶
Run isort utility to sort Python imports:
$ pip install -e .[develop]
$ isort --apply
Then run pycodestyle and Pylint code style checks:
$ pip install -e .[tests]
$ pycodestyle meta_package_manager
$ pylint --rcfile=setup.cfg meta_package_manager
Build documentation¶
The documentation you’re currently reading can be built locally with Sphinx:
$ pip install -e .[docs]
$ sphinx-build -b html ./docs ./docs/html
For a smooth release, you also need to validate the rendering of package’s long description on PyPi, as well as metadata:
$ pip install -e .[develop]
$ ./setup.py check -m -r -s
Release process¶
Start from the develop
branch:
$ git clone git@github.com:kdeldycke/meta-package-manager.git
$ cd ./meta-package-manager
$ git checkout develop
Install development dependencies:
$ pip install -e .[develop]
Revision should already be set to the next version, so we just need to set the released date in the changelog:
$ vi ./CHANGES.rst
Create a release commit, tag it and merge it back to master
branch:
$ git add ./meta_package_manager/__init__.py ./CHANGES.rst
$ git commit -m "Release vX.Y.Z"
$ git tag "vX.Y.Z"
$ git push
$ git push --tags
$ git checkout master
$ git pull
$ git merge "vX.Y.Z"
$ git push
Push packaging to the test cheeseshop:
$ ./setup.py register -r testpypi
$ ./setup.py clean --all
$ ./setup.py sdist bdist_egg bdist_wheel upload -r testpypi
Publish packaging to PyPi:
$ ./setup.py register -r pypi
$ ./setup.py clean --all
$ ./setup.py sdist bdist_egg bdist_wheel upload -r pypi
Update revision with bumpversion
and set it back to development state by increasing the patch
level.
$ git checkout develop
$ bumpversion --verbose patch
$ git add ./meta_package_manager/__init__.py ./CHANGES.rst
$ git commit -m "Post release version bump."
$ git push
Now if the next revision is no longer bug-fix only, bump the minor
revision level instead:
$ bumpversion --verbose minor
$ git add ./meta_package_manager/__init__.py ./CHANGES.rst
$ git commit -m "Next release no longer bug-fix only. Bump revision."
$ git push