VS Code Python Release Plan V2025.12.0: A Comprehensive Guide

Hey everyone! Let's dive into the release plan for v.2025.12.0 of the Python extension for VS Code. This document outlines all the steps and timelines to ensure a smooth and successful release. We'll cover everything from version bumping to final release and even point release procedures. So, grab your coffee, and let's get started!

General Notes

It's super important that all dates align with VS Code's iteration and endgame plans. We need to stay in sync with the VS Code release cycle to avoid any hiccups. Remember, guys, the feature freeze is set for Monday @ 17:00 America/Vancouver, XXX XX. After this deadline, commits to main should only address bugs found during endgame testing until the release candidate is ready. This helps us ensure stability and quality in our releases.

Release Candidate (Thursday, Jul 31)

Mark your calendars: the release candidate is scheduled for Thursday, July 31st. This Thursday falls during our testing week, so branching needs to happen then to freeze the release with only the correct changes. Any last-minute fixes will be treated as candidates for the release branch and will require team approval. This process ensures that only thoroughly vetted changes make it into the final release.

Other important notes to keep in mind:

• Third-Party Notices are automatically added by our build pipelines using https://tools.opensource.microsoft.com/notice.
• The version number for this release is in the issue title and can be substituted wherever you see [YYYY.minor]. This helps keep everything consistent and organized.

Step 1: Bump the Version of main to Be a Release Candidate ❄️

This step involves updating the version in our package.json and related files to mark main as a release candidate. These steps with the snowflake (❄️) indicate that they should happen while main is frozen (🥶). It’s like putting on the brakes so we can make these critical changes without disruption.

• First, checkout to main on your local machine and run git fetch to ensure your local repo is up-to-date with the remote. We want to make sure everyone is working with the latest version.
• Next, create a new branch called bump-release-[YYYY.minor]. This branch will house all the version-bumping changes. Think of it as our temporary workshop for this task.
• Now, let's update pet (Python Environment Tools):
  • Go to the pet repo and check main and the latest release/* branch. If there are new changes in main, create a branch called release/YYYY.minor (matching the Python extension release major.minor). This ensures our environment tools are aligned with the extension release.
  • Update build\azure-pipeline.stable.yml to point to the latest release/YYYY.minor for python-environment-tools. This step links our build pipeline to the correct version of pet.
• Change the version in package.json to the next even number. (🤖) This is an automated step (🤖), making it a breeze.
• Run npm install to make sure package-lock.json is up-to-date. At this point, you should see changes only to the package.json and package-lock.json files, which update the version number. (🤖) Again, this is mostly automated.
• Update ThirdPartyNotices-Repository.txt as appropriate. You can check the commit history to see if any code has been pulled directly into the repository from elsewhere. If unsure, check with the team. We want to ensure proper attribution and compliance.
• Finally, create a PR from your branch bump-release-[YYYY.minor] to main. Add the `