V2025.12.0 Release Plan: A Detailed Guide For VS Code Python

Hey everyone! Let's dive into the release plan for v2025.12.0 of the Python extension for VS Code. This guide will walk you through all the steps, from feature freeze to the final release, ensuring a smooth process. We'll cover everything, so you know exactly what to expect and when.

General Notes

It's crucial to align all dates with VS Code's iteration and endgame plans. Keeping in sync with the VS Code schedule helps us ensure compatibility and a seamless user experience. Remember, our goal is to deliver a high-quality extension that works perfectly within the VS Code ecosystem.

Feature freeze is scheduled for Monday at 17:00 America/Vancouver, XXX XX. After this point, only bug fixes are allowed on the main branch until the release candidate is ready. This freeze ensures we can focus on testing and stabilization without introducing new features that could cause instability. So, let's get those features in before the deadline!

Release Candidate (Thursday, Jul 31)

This Thursday falls during the TESTING week, guys! Branching should occur this week to freeze the release and ensure only the correct changes are included. Any last-minute fixes will be treated as candidates for the release branch and require team approval. This is super important to maintain stability and quality.

Other important notes:

• Third-Party Notices are automatically added by our build pipelines using https://tools.opensource.microsoft.com/notice.
• The release number is in the issue title; substitute it wherever you see [YYYY.minor].

Step 1: Bumping the Version on main to a Release Candidate ❄️

This first step is critical. We need to bump the version of main to a release candidate, updating third-party notices and the package-lock.json file. Steps marked with ❄️ indicate actions to be performed while main is frozen 🥶. Think of it like putting the codebase in a temporary icebox to ensure no accidental changes slip in during this process.

Here’s the breakdown:

• [x] First, checkout to main on your local machine and run git fetch to ensure your local copy is up-to-date with the remote repository. This prevents any conflicts and ensures you're working with the latest code. It's like stretching before a workout – essential for a smooth process!
• [x] Next, create a new branch called bump-release-[YYYY.minor]. This branch will isolate your changes for the version bump, making the process cleaner and easier to review. Think of it as your personal workspace for this task.
• [ ] Now, it's time to update pet:
  • [ ] Head over to the pet repo and check both the main branch and the latest release/* branch. We need to make sure our environment tools are in sync too! If there are new changes in main, create a branch called release/YYYY.minor (matching the Python extension release major.minor).
  • [ ] Update build\azure-pipeline.stable.yml to point to the latest release/YYYY.minor for python-environment-tools. This ensures our build pipeline uses the correct version of the environment tools for the release.
• [ ] Change the version in package.json to the next even number. (🤖) This is a crucial step as it signifies the release candidate version. Remember, even numbers for releases! (🤖)
• [ ] Run npm install to make sure package-lock.json is up-to-date. You should now see changes to the package.json and package-lock.json files, but only related to the version number update. (🤖) This command ensures our dependencies are locked in place.
• [ ] Update ThirdPartyNotices-Repository.txt as appropriate. To do this, review the commit history and identify any code pulled directly into the repository from external sources. If unsure, consult the team. It's essential to give proper credit where it's due!
• [ ] Finally, create a PR from your branch bump-release-[YYYY.minor] to main. Add the `