We will be using the Semantic Commit Message naming convention. This standard involves writing commit messages in the following format:

<type> (optional scope): <description> 

[optional body]

[optional footers]

This portion of the commit messages broadly explain what the commit accomplished. Below is a list of all of the commit types that we will be using:

• feat: Used for commits that add a new feature to the code.
• fix: Used for commits that patch a bug.
• docs: Changes to documentation or comments.
• style: Used for commits that change how the code is formatted.
• chore: Commits that solely change Gradle or GitHub specific files.
• refactor: Used for commits that rework preexisting features.
• pref: Refactors done specifically for the purpose of improving code performance.

This indicates what portion of the code is being changed. This may look something like the following example: feat(vision): add object tracking

This part of the commit message should provide a brief summery of what the commit does. The description should be written in the present tense. This should look something like the following example:

feat: implement autonomous pathfinding

In the event that a commit contains breaking changes (changes that may break pre-existing code), you MUST place a exclamation mark after the commit type or, if included, the scope. This would look something like the following:

feat!: add new drivetrain object
An optional footer titled BREAKING CHANGE may be included. Including this would look something like this:
feat!: add new drivetrain object

BREAKING CHANGES: removed old drivetrain object

If you still have questions regarding our commit naming standards, please refer the this site for more information. Alternatively, you may message Cameron with any questions that you may have.

To maintain consistency and clarity in our development process, we will adhere to the following branch naming conventions. These conventions help in easily identifying the purpose and status of a branch at a glance.

Each branch name should start with a type that indicates the nature of the work being done. Here are the types we will use: -feature/: For new features or enhancements. -bugfix/: For bug fixes. -hotfix/: For critical fixes that need to be addressed immediately. -docs/: For commits focusing primarily on writing or adjusting documentation. -text/: For commits that focus on testing code. These branches are non-permanent, and will be deleted at some point. -github/: For commits related specifically to GitHub workflows, actions, or repository-level integrations. -release/: Used solely for our weekly code release. For more information, see .

The branch name should follow the format:

<type>/<short-description>

The branch name should be all lowercase, hyphen separated, and use only alphanumeric characters.

Here are some examples of branch names: -feature/object-detection-pipeline -bugfix/rotation-rounding-error -hotfix/driver-station-crash -docs/arm-stabalization -release/v1.0.0 By following these conventions, we ensure a more organized and efficient workflow, making it easier for team members to collaborate and manage the codebase effectively.

If you still have questions regarding our branch naming standards, please refer the this site for more information. Alternatively, you may message Cameron with any questions that you may have.

Our versioning system follows the Semantic Versioning specification, which helps in maintaining a clear and predictable release process. This system uses a three-part version number format: MAJOR.MINOR.PATCH. This system will be used whenever something is merged into the main branch.

MAJOR: Incremented when there are incompatible API changes or significant updates that may break backward compatibility. MINOR: Incremented when functionality is added in a backward-compatible manner. PATCH: Incremented for backward-compatible bug fixes.

The version number should be formatted as follows: v..

Here are some examples of version numbers: v2.0.0: Indicates a major release with breaking changes. v1.3.5: Represents a minor update with new features and some bug fixes. v1.2.1: A patch release addressing specific bugs without adding new features. By adhering to these versioning guidelines, we ensure that our releases are consistent and easy to track, facilitating smoother updates and maintenance.

If you still have questions regarding Semantic Versioning, please refer the this site for more information. Alternatively, you may message Cameron with any questions that you may have.