VS Code July 2025 Recovery 1 A Comprehensive Milestone Guide
Hey guys! We're diving deep into the July 2025 Recovery 1 milestone for VS Code. This comprehensive guide will walk you through every step, ensuring we hit all the marks for a smooth and successful recovery release. Let's break it down, keep it casual, and make sure we're all on the same page.
Milestone Creation and Version Bumping
First things first, milestone creation is key. We need to make sure the July 2025 Recovery 1 milestone is officially created. This sets the stage for tracking our progress and keeping everything organized. @osortega, you're on it!
Next up is bumping the version number. This is more than just a formality; it’s about ensuring the integrity of our release process. When we bump the version number, we also run npm i to update the package-lock.json. This file is crucial for maintaining consistent dependencies across different environments. We need to double-check that there are no other unintended changes in the package-lock.json. Consistency is king, guys! This task also falls under @osortega’s capable hands.
Candidate Issue Management
Identifying Candidate Issues
Now, let’s talk about candidate issues. These are the bugs and hiccups we're targeting in this recovery milestone. We have a dedicated query to find these potential fixes: 🔖candidate issues. This link is your golden ticket to seeing what's in the pipeline. The goal here is to make sure we're addressing the most pressing issues that our users are facing. No one likes a buggy editor, right?
Assigning and Reviewing
Once we've got our list of candidate issues, the next step is assigning them to the recovery milestone. Our awesome team will take ownership and start digging in. But it’s not just about assigning; we need to review these candidates thoroughly. Does the issue really fit the scope of a recovery milestone? Is it critical enough? If it passes the review, then we officially assign it to the milestone. This is all about making smart choices and focusing our efforts where they matter most.
Code Review and Cherry-Picking
Peer Review is Essential
Alright, we’ve got our issues assigned, and now it’s time to get down to the nitty-gritty. All candidate fixes need to be peer-reviewed. This is a non-negotiable. Fresh eyes catch things that solo debugging might miss. Peer review is our safety net, ensuring that the code we're pushing is solid and doesn't introduce new issues. It's like having a second pair of eyes on your work – always a good thing.
Pushing to Main and Cherry-Picking
Once a fix gets the thumbs-up from the peer review, it's pushed to main. This is where the magic starts to happen. But we’re not done yet! Because this is a recovery release, we need to get these fixes into our release branch. That’s where cherry-picking comes in. We carefully select the commits that contain our fixes and apply them to the release branch. Think of it as hand-picking the best cherries for our pie – only the finest fixes make the cut!
Insider Builds and Testing
Initiating Insider Builds
Now that we've got our fixes in the release branch, it's time to initiate an insiders build from main. This is where our early adopters and keen-eyed testers get to kick the tires. Insider builds are crucial because they give us real-world feedback before we unleash the recovery release on everyone. It’s like a sneak peek before the big show.
Rigorous Testing in Insiders
Once the insiders build is out, our team jumps into testing mode. This is where we put those fixes through their paces. We're looking for regressions, edge cases, and anything else that might cause trouble. Testing in the insiders environment helps us catch issues early, saving us headaches down the road. The more eyes on it, the better!
vscode.dev Testing
And if we have any candidates specifically for vscode.dev, we build and manually release an Insider build just for that. Again, testing is key. We make sure those vscode.dev-specific fixes are solid before they go live. Testing, testing, 1, 2, 3!
Stable Build and Verification
Building the Stable Release
With the insiders build vetted and any necessary tweaks made, it’s time to build the stable release for all platforms. This is the build that everyone will be using, so we need to make sure it’s rock-solid. @osortega, this one’s on your plate! We're talking Windows, macOS, Linux – the whole shebang. A stable release is a happy release.
Verification on Stable Build
Once the stable build is ready, we need to verify those fixes. This is our final sanity check. We go through each issue and confirm that the fix is working as expected in the stable build. If it’s verified, we slap on the verified label. It’s like giving our fixes a gold star – they’ve earned it! @osortega, you're leading the charge on this one too.
Ensuring a Clean Release Branch
Before we go any further, we take a moment to check the release branch. We want to make sure that no other commits have snuck in there. We use this nifty comparison tool: https://github.com/Microsoft/vscode/compare/release/<x.y>. It’s all about ensuring that our release is exactly what we expect it to be – no surprises!
The 24-Hour Rule
Here’s a crucial rule of thumb: the insiders build with all our candidate fixes needs to be in the wild for at least 24 hours before we do the recovery release. This gives us time to catch any last-minute issues that might pop up. Of course, there’s an exception: if @kieferrm gives the explicit thumbs-up, we can proceed sooner. But generally, we like to give it that 24-hour buffer.
Release Notes and Sanity Testing
Crafting the Release Notes
Now, let’s make sure everyone knows what’s in this release. We need to update the release notes. This isn’t just a dry list of fixes; it’s our chance to communicate with our users, to tell them what we’ve been up to. We also include a link to a query for the fixed issues, so folks can dive into the details if they want. @ntrogh, your writing skills are needed here!
Sanity Testing Across Platforms
Before we hit the big red button, we need to do some serious sanity testing. This is our comprehensive checklist to ensure everything is working as expected across different platforms and installers. We’re talking Windows, macOS, Linux – every flavor and variant.
Windows Sanity Testing
For Windows 64-bit, we’re testing the System Installer, User Installer, Archive, Server, and CLI. Windows ARM64 gets the same treatment. We leave no stone unturned. Each owner must ensure that everything runs smoothly on their respective platforms.
macOS Sanity Testing
macOS Intel and ARM64 both get the full workup: Archive, Universal Archive, Server, and CLI. We make sure it purrs like a kitten on both architectures.
Linux Sanity Testing
Linux x64 needs to pass the tests for Archive, DEB, RPM, and Snap. We cover all the popular package formats. And for Linux Server and CLI, we’re using Docker to test x64, ARM32, ARM64, x64 Alpine, and ARM64 Alpine. It’s a Linux party, and everyone’s invited!
Publishing and Official Release
Website and Stable Build Publishing
Alright, we're in the home stretch! Time to publish the website. This is where the world gets to see our shiny new release. @rzhao271, you're the maestro of the website publishing. Let's make it look good!
Next up, we publish the stable build. This is the moment we’ve all been waiting for. The bits are out there, ready for download. @osortega, you're on point for this one! It’s like releasing a flock of well-behaved digital birds into the wild.
vscode.dev Deployment (If Applicable)
If we had any vscode.dev candidates, we need to trigger the vscode.dev Deploy pipeline. This pipeline ensures that our web-based editor is up-to-date with the latest fixes. We target the prod deployment for the release/x.y branch.
Requesting Approval
And here’s an important step: we request approval from another team member at the necessary step to deploy the vscode.dev build. It’s always good to have a second set of eyes on these things. @osortega, you’re coordinating this too.
Creating the Official Release and Closing the Milestone
Tagging the Release
Now, for the official stuff. We need to create an official release. This involves a few Git maneuvers. First, we make sure we’ve pulled the release branch. Then, we create a tag: git tag <x.y.z> release/<x.y>. This tag marks the specific commit that corresponds to our release.
Pushing the Tag
Next, we push the tag: git push origin <x.y.z>. This makes the tag visible to everyone on the team and in the repository.
Creating a GitHub Release
We’re not done with Git just yet! We also need to create a GitHub release. We head over to the GitHub tags and click the ... > Create Release button. We use the correct title and description from our release notes. Check out this example if you need a reference.
Closing the Milestone
Last but not least, we close the milestone on GitHub. This signifies that we’ve completed all the tasks and the release is officially out the door. @osortega, you get the honors! It’s like putting a big, satisfying checkmark on our to-do list.
Conclusion
So, guys, that’s the rundown of the July 2025 Recovery 1 milestone. It’s a comprehensive process, but by following these steps and working together, we’ll ensure a smooth and successful release. Let’s keep the communication flowing, stay vigilant, and make this recovery milestone a resounding success!