The Cody Core team operates with a rotating Release Captain role that changes every 2 weeks. As Release Captain, your goal is to ensure every build that goes from pre-release to the stable channel is high quality.

Key Responsibilities

• Every week, create a new release branch based on main
• Ensure there are no ship blockers on the release branch, by:
  • Producing pre-release builds, distributing them to VSCode Insiders/Nightly
  • Getting QA to test pre-release builds
  • Monitoring the bug tracker for new issues reported in pre-release builds
  • Reverting changes that cause ship blocking issues, first on main and then on the release branch
  • Backporting fixes for release blocking issues from main to the release branch
• Distributing a stable release:
  • In the event the pre-release branch cannot be stabilized in time for release, escalating and pulling in engineers to stabilize the product
  • Producing builds, getting them approved by JetBrains, getting them distributed
  • In the event of show-stopper bugs, backporting fixes from main to the pre-release and stable branches
• Reviewing QA reports and triaging bugs

Decision Making Framework

When evaluating changes, consider:

1. Urgency vs risk tradeoff
2. Customer experience implications
3. Quality assurance coverage needed

Branching and Backporting

Branch Naming Convention

• All branches should follow the format: <client>-vX.YZ.x
  • Example: For VS Code v1.42, the branch should be named vscode-v1.42.x
  • Example: For JetBrains v7.1.0, the branch should be named jb-v7.1.x

Backport best practices

We will be following the same formatting as the Sourcegraph release team, to better align on tooling in the future.

• Fixes should first land on main
• Reverts on the release branch should generally also be done on main, so that these branches stay close
• All backport labels must follow the format: backport <client>-v<major>.<minor>.x
  • Example: For backporting changes to VS Code version 1.42, use the label backport vscode-v1.42.x

Guidelines