Skip to content

Latest commit

 

History

History
130 lines (79 loc) · 3.41 KB

coding-guidelines.md

File metadata and controls

130 lines (79 loc) · 3.41 KB
Raw

Coding Guidelines

Most Important

  • Work in your own forks.

  • Create issues for proposed changes. Discuss major changes there before submitting a PR.

  • Name branches as 123-my-issue-title (use "Create a branch" on issue page)

  • Strive for consistency within and across projects unless you have a very good reason to do otherwise.

  • Limit work just to the topic of a branch, and nothing more.

  • NEVER reformat code in a branch.

  • Use the biocommons package template for new code. Existing repos are periodically synchronized with that repo.

  • Don't x.y.z pin dependencies. In Python, use ~=x.y

  • Strive for DRYness (Don't Repeat Yourself)

  • Test your code before committing

Coding

  • All source code is licensed under the Apache License, 2.1.

  • Packages should use the biocommons.example repo to get started, for consistency. Updates to the example will occasionally be merged into the repos.

  • branching main, dev, feature branches, nn-

  • 1-3 project leads are code owners. They are expected to meet and discuss as needed.

  • Code owners may commit directly. Everyone else needs to submit a PR from a fork.

  • All branches and PRs should be tied to a github issue for that repo with standard naming conventions.

  • PRs should include docs and tests (but up to the code owners).

  • All Python packages must use the same structure (pyproject.toml, __version__ from git, etc). We'll sync with biocommons.example periodically to ensure consistency.

  • most development should be the result of an issue

Issues

PRs

CI/CD

github actions → biocommons pypi

Code formatting

  • black
  • isort
  • pylint

Versioning

All biocommons tools use Semantic Versioning. Package versions are derived from git tags in order to ensure that released software always corresponds to a git tag.

Branching and Merging Model

Branching Strategy{.right}

  • main is the release branch.
  • release-specific branches, branched off of main and named as x.y, support concurrent patch release off the x.y
  • dev is the development branch for integration testing.
  • feature development occurs in feature branches, branched off of dev and named for the corresponding issue (e.g., 42-bang-the-rocks-together).
  • bug fixes occur in branches off of the affected release. As necessary, those fixes should be then merged back to main.

If a project needs a new development branch for a major release, the Architectural Team will address the issue.

Merging

  • Tests must pass in order to be merged. Branches that are failing tests will not be merged.
  • Merging to main and dev is restricted to code owners.

Coding Guidelines

example repo

Code in biocommons org

Example repo Consistent setup from template

versioning

Pull requests

  • squash if you want before the PR
  • branch names 6-go-bonkers
  • Merge commit message used as default for changelog

Review criteria

Tagging, releasing, changelogs

Other