Development and release guidelines - Emerge-Lab/gpudrive GitHub Wiki

Release tracker

v.0.3.0

We are currently working at release v0.3.0.

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"

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.