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.
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 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
Tagging, releasing, changelogs