contributing.md

Contributing

Linting and Formatting

Not standardized. Read (internal) Formatting & Linting.

Best Practices

• Sign your commits.
• Learn Markdown.

Development Workflow

We use a modifed version of GitFlow.

• "feature branches" have a specific prefix:
  • feat/ for features and updates
  • fix/ for bugfixes and hotfixes
  • refactor/ for large internal changes
  • style/ for code style changes (white-space, formatting, etc.)
  • chore/ for no-op changes
  • docs/ for documentation
  • perf/ for performance improvements
  • test/ for test case updates
  • or other "types" from Conventional Commits
• "develop" branch is usually main,
  ^{but can exist as a long-lived multi-feature branch prefixed with dev/}
• "release branches" (as needed) are prefixed with release/
• "hotfix branches" are prefixed fix/
• "master branch" is always main

Our development site is always up-to-date with main branch.

Note The development site is only accessible behind the TACC Network.

Our production site is built from a specific commit.

Release Workflow

Only appointed team members may release versions.

1. Create new branch for version bump.
2. Update CHANGELOG.md.
3. Update version:

• npm version N.N.N
• edit version in pyproject.toml

1. Review. Commit. Push.
2. Create release and tag on GitHub.
3. Annotate Github's tag:
   bin/annotate-tag.sh vN.N.N
   (where N.N.N is the version tag)
4. Overwrite remote tag with annotated one:
   git push --tags --force