-
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
-
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
github actions → biocommons pypi
- black
- isort
- pylint
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.
- 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.
example repo
Code in biocommons org
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
- https://gist.github.com/chalasr/fd195d83a0a01e4291a8
- Atomic Commits http://en.wikipedia.org/wiki/Atomic_commit#Atomic_Commit_Convention
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
- We support most recent 3 Python releases; https://devguide.python.org/versions/
- 3.9, 3.10, 3.11 now
- drop 3.9 and add 3.12 when 3.12 is available