Notes for developers
Checklist for releasing a new Rockpool version
Make a release candidate branch
developbranch on internal gitlab
Make sure the version number in
version.pyhas been bumped. We use semantic versioning:
(postN)is only for hotfixes
rc/...to make sure all changes are merged
Make a merge request from
Get all primary developers to review the merge request, ensure that all suggested modifications are included
Ensure that all pipelines pass, including manual pipelines
git log X..Y --oneline
Once the merge has succeeded, delete the
Make and push a tag to the
masterbranch for the new version (i.e. “vX.Y.Z”)
Once all CI tasks have succeeded, a manual CI task “pypi_deploy” will be available. Run this task to deploy to PyPI. This task must be run from the internal Rockpool repository
A pull request for the conda feedstock should be created automatically by a conda-forge bot. Check and merge this PR to bump the version on
Bump the version number in the
developbranch to something like “vX.Y.Z.dev”
### Added ### Changed ### Fixed ### Deprecated ### Removed ### Security
Questions to resolve for each merge request
During code review for each merge request, make sure all of the following questions are addresssed. If any boxes are not ticked, there should be a good reason why not.
- [ ] Are there user-facing tutorials?
what does the feature do? how to use it?
what are the limitations of the feature? what it doesn’t do?
troubleshooting guide: what to do in case of issues/bugs/problems?
FAQ: what are the most common mistakes or confusions?
[ ] Is each tutorial minimal and relatively self-contained?
[ ] Is each tutorial didactic?
[ ] Is the developer documentation updated with any new modules or changes?
[ ] Are the packages / tutorials integrated into the documentation TOC?
[ ] Are all class / method / function / file links in the tutorials working correctly?
[ ] Do all user-facing class attributes have docstrings in
[ ] Do all non-user-facing class attributes have a leading underscore? (e.g.
[ ] Are all user-facing class attributes either
[ ] Do Rockpool modules obey the standard Rockpool API for
as_graph()implemented, if at all possible, for any new modules
[ ] Does every
__init__.pyhave an initial docstring block, describing what the package / sub-package does and contains?
- [ ] Are there tests implemented?
[ ] unit tests?
[ ] integration tests?
[ ] interface tests?
[ ] performance tests?
[ ] code coverage measured?
[ ] Is
[ ] Is the implementation minimal? i.e. the simplest possible way of implementing the functionality