Developer Guide

Overview over the development process. (The developer guide is an evolving document. Please modify as necessary.)

Development

Development happens on the master branch. The master branch is supposed to be installable and produce correct results at any time.

Pull Request, Review, Merge Model

• We use a Pull Request, Review, Merge model for code development with continuous integration: code should only be added to master through a PR. The PR has to pass
  • code review by another developer with write access to the repo
  • unit tests (all existing tests pass)
  • coverage testing (new code comes with tests to check the majority of its functionality)
• For each PR, the whole test suite is run (on Travis CI). If your PR does not pass tests then it will typically not be accepted. Ask for help (ping other developers with @NAME mentioning them in the comments of your PR).
• PRs are typically merged (or rebased onto master) but sometimes the developer in charge can also decide to squash all commits (especially when there are many incremental commits) in order to keep the history clean.

Contributing

Fork the repository and create a PR or, if you have write access to the repo, create a branch in the repo. Name the branch issue-XXX-SUMMARY where you typically reference an issue in the issue tracker and SUMMARY is a very short description, e.g., issue-10-dx.

Discuss all issues related to a PR in the comments to the PR.

Release management

• We use semantic versioning MAJOR.MINOR.PATCH (i.e., briefly, major revision changes whenever the API changes in backwards-incompatible manner, MINOR changes for new features, PATCH changes for fixes that correct functionality; as long as MAJOR == 0, we can break the API with increasing MINOR.)

• Releases are cut from the master branch and tagged with MAJOR.MINOR.PATCH (note: the release tag determines the tag because we use versioneer, which obtains the release number from the git tag). We do from the master branch:

  1. git tag <major>.<minor>.<patch>
  2. git push --tags

• Note: the tags need to be pushed to GitHub with git push --tags. (You can add text to the releases on GitHub.)

• This will automatically trigger a github action (named 'deploy') to using pypa's build tool to create a tarball & pure Python wheel and upload it to https://test.pypi.org/project/GridDataFormats

• Once uploaded to testpypi, please check locally that the testpypi build is working as intended. In a clean environment do:

  1. `pip install -i https://test.pypi.org/simple/ --extra-index-url https://pypi.org/simple GridDataFormats=="version number"
  2. pip install pytest
  3. pytest --pyargs gridData

• After this, do a Github release and this will automatically trigger the deploy action to deploy the tarball and wheel to the standard pypi repository.

• Packages are published from the tagged release (pip package, conda package, tar balls on GitHub, zenodo).

  • pip and source tarballs on github: on publication of a Github release from the tag (just add some text)
  • conda: follow instructions in MAINTAINER.md
  • zenodo tarballs and DOIs are automatically minted

• Docs are managed on mdanalysis.org (only the latest develop) and ReadTheDocs (releases and latest) and automatically update.