Skip to content

Developer Guide

Jump to bottom
Oliver Beckstein edited this page Nov 13, 2017 · 21 revisions

Overview over the development process of alchemlyb and alchemtest. (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. We therefore insist on merging code that is covered by tests to about 90% coverage level (i.e., 90% of the lines of code are exercised by tests).

Pull Request, Review, Merge Model

  • We use a Pull Request, Review, Merge model for code development with continuous integration: code can 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-Amber-parser (to reference issue #10).

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. python setup.py sdist bdist_wheel
    3. twine upload dist/*

  • Packages are published from the tagged (pip package, conda package (TODO), tar balls on GitHub); zenodo DOIs and snapshots are automatically minted.

  • Docs are managed on ReadTheDocs and automatically update.

Clone this wiki locally