Skip to content

Coding Guidelines

For the collective good of the organization, projects must adopt and adapt to the technical standards and coding guidelines created by the Architectural Team, or present a rationale for doing otherwise. In general, biocommons projects should operate consistently and coherently; divergence of behavior, especially needless divergence, is detrimental to the overall goes.

  • code maintainers
  • main, dev, feature branches, nn-
  • use and keep up-to-date with template

  • most development should be the result of an issue


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

  • 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.


  • 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.

alt blah

Coding Guidelines

example repo

Code in biocommons org

License = Apache Example repo Consistent setup from template

versioning - semver - no v - directly from tag when possible

  • branching model
  • multiple version branches
  • dev in forks
  • protected branches
  • Atomic Commits

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