Development and release guidelines

Release tracker

v.0.3.0

We are currently working towards release v0.3.0. Features to be included in this release are found here.

General Guidelines

1. Branching Strategy

• Main Branch (main): This is the stable branch. All feature development, bug fixes, and hot-fixes are directly committed or merged here. Thoroughly tested and verified code should be present on this branch.
• Feature Branches: Each new feature, bug fix, or enhancement should be developed in its own branch, branched off from main. These branches are merged directly into main after review and testing.
• Releases: Release tags are used to mark certain points on the main branch.

---
title: GPUDrive dev workflow example
---
    gitGraph
        commit
        branch feature/behavioral-cloning
        branch feature/resample-scenes
        branch release

        checkout release
        commit id: "Current release" tag: "v0.2.0"

        checkout feature/behavioral-cloning
        commit id: "Behavioral Cloning 1"
        commit id: "Behavioral Cloning 2"

        checkout feature/resample-scenes
        commit id: "Resample Scene 1"
        commit id: "Resample Scene 2"
        commit id: "Resample Scene 3"

        checkout main
        merge feature/behavioral-cloning id: "Merge BC"

        checkout feature/resample-scenes
        commit id: "Resample Scene 4"

        checkout main
        merge feature/resample-scenes id: "Merge RS"
        merge release id: "New Release" tag: "v0.3.0"

Loading

2. Development Workflow

1. Create a Feature Branch:
   • Branch off from main using a descriptive name for the branch, e.g., feature/imitation-learning or bugfix/fix-memory-leak.
2. Commit Changes:
   • Make frequent, small commits with clear and concise commit messages.
   • Follow the commit message format: type(scope): description [ticket/reference]
   • Types can include feat, fix, docs, style, refactor, test, or chore.
   • Use pre-commit hooks for linting, formatting, and other checks before committing.
3. Open a Pull Request (PR):
   • Once development in the feature branch is complete, open a PR to main.
   • Ensure that the PR description includes a summary of changes, any related issues, and testing steps.
4. Code Review and Testing:
   • At least one other team member must review the PR before merging.
   • Use automated tests to ensure the code works as expected and doesn't introduce new issues.
   • Conduct performance tests, such as the learning benchmark.
5. Merge to Main:
   • After approval, the PR can be merged into main.
   • Delete the feature branch after merging to keep the repository clean.

3. Release Process

1. Prepare for Release:
   • Determine the release date based on the project milestones.
   • Review the main branch to ensure all features and fixes are ready for release.
2. Create a Release Candidate Branch:
   • Branch off main to create a release-X.Y branch (where X.Y is the version number).
   • Conduct final testing on this branch to identify and fix any remaining issues.
3. Tagging and Versioning:
   • Once testing is complete, update the version number in the codebase and create a Git tag for the release.
   • Tag format: vX.Y.Z, where X.Y.Z follows semantic versioning (e.g., v1.2.3).
4. Merge to Main:
   • After tagging, merge the release-X.Y branch into main.
   • Push the changes and tag to the remote repository.
5. Release Announcement:
   • Update the project documentation, including the changelog, and notify the team and users of the new release.
6. Post-Release:
   • Archive the release-X.Y branch if no further changes are expected.