Iteration Plan for March 2026 [DRAFT]

[kieferrm]

Important

Update to our shipping and planning cycle

Every month since Summer 2025, we shipped one Stable release with broad new functionality and 3–4 patch releases with select new functionality and bug fixes. Over the last weeks, we have been working on streamlining our development and delivery process. Starting March 9, 2026, we’ll ship a new Stable release every week. Endgame will now be folded into our weekly activities. Issues will be assigned to milestones named after the release version they represent.

By mid-March, we’ll have defined the way how we keep you informed about the work that is happening and planned, roughly aligned to calendar months. Please stay tuned.

[iwangbowen]

Always looking forward to new updates

[Bearmancer]

You guys are doing fabulous work on VSC!

[spartanatreyu]

By mid-March, we’ll have defined the way how we keep you informed about the work that is happening and planned, roughly aligned to calendar months. Please stay tuned.

This is confusing and concerning.

I can see three things happening:

1. A change is revealed in patch notes, the change has occurred, the user can interact with the change.
2. A change has occurred, but won't be revealed until the patch notes are released. The user isn't aware of the change, yet may be affected by it.
3. An upcoming change is revealed in patch notes, but due to recurring unforeseen issues the change keeps getting pushed back. By the time the feature is released, the user has forgotten about the original announcement and is now affected by a change they are not aware of.

---

If increasing the release cadence is the goal, maybe it would be better to have multiple release channels:

• Nightly (for development/testing only)
• Weekly (for early adopters and extension developers)
• Monthly (for stability)

---

As a user I don't think a non-bugfix/non-patch release can be responsibly pushed out without release notes.

As the office "fixer", I don't want to have to drop everything and go around to everyone's computer to change a vscode setting on any random week, I have my own things to do, and sometimes they will take up the whole week. I imagine extension developers would feel the same way.

[kieferrm]

As a user I don't think a non-bugfix/non-patch release can be responsibly pushed out without release notes.

As before, every release will have release notes. We used to publish monthly plans labeled "iteration-plan". We'd like to continue to give you an idea of what's coming in the next 1-4 weeks and we're working on what this kind of plan document will look like given that we release a new stable every week.

[lppedd]

I like more frequent deliveries from an engineering perspective.
However, I'm not sure how much I like it from a user and extension developer perspective. This means having to deal with customers on a much wider range of versions, and while it might seem a "nothing burger" at first, it might add quite the overhead to extension developers, support people, and sysadmins that have to deploy those versions to internal users. It might sound dumb, but seeing a number increase too fast might scare people.

[garretwilson]

I like more frequent deliveries from an engineering perspective.

@lppedd I also like more frequent deliveries in theory! If we were comparing apples to apples, sure, I'd like more frequent deliveries that are just as stable as monthly releases. The question is: is this an "all things being equal" proposition, or a tradeoff analysis? Will we be trading faster releases for a less stable product, with things thrown in willy-nilly with no testing, and with no way to provide feedback? Look at the record.

As before, every release will have release notes.

@kieferrm honestly isn't that a bit misleading? What are in the release notes usually? All the big, new, fancy features that the GitHub team is rushing out because there is pressure from above to add something new and shiny to keep ahead in the market? But what about the things that matter in day-to-day, minute-to-minute, under the hood work that can make or break productivity?

Broken Compaction Algorithm

In v1.110 you introduced a new conversation summarization algorithm. Was that in the release notes for v1.110? Not that I can find. Sure, I can infer that you renamed "summarization" to "compaction", but there's no note that the algorithm changed.

Turns out the new algorithm is completely broken. In v1.109, "summarization" would leave the context window way less than 25% full. Now the new algorithm in v1.110 (which was not in the release notes) still leaves the context window 50% full or more. Even worse, it apparently accumulates information, so after a few days in a session, "compaction" leave the context window 75% full, etc., meaning no headway is possible. This is a critical bug, yet in #299810 I can't even get anyone on the GitHub Copilot team to acknowledge it, let alone discuss it with me.

Unstoppable AI

Let's take another example. There is a bug in GitHub Copilot that in certain conditions makes it impossible to stop the AI. Yes, that's right—the AI will just run loose, and there is no way to stop it without trying to close VS Code. There are actually several scenarios: #291713, #301004, and #295351 (inappropriately closed). Unstoppable AI is a security issue, as I've stressed in the comments. Did these security issues appear in the release notes? No. Are we any closer to resolving them? Who knows? The GitHub Copilot team have acknowledged some of these, but don't appear to know what causes this dangerous situation. Will a weekly cadence make it more or less likely that these sort of security issues get fixed?

Thus the question is: with the new weekly schedule (which in theory we all want, "all things being equal"), are we trading the already degrading VS Code GitHub Copilot quality for an even more rapid decline? Will more bugs like #299810 slip out the door because there was insufficient time for testing? Will developers on the team want, or be allowed, or have time to address bugs such as #291713, #301004, and #295351; or even read bugs such as #299810? Or will they be pushed to work on the new glittery, shiny new-thing-of-the-week to go in those release notes you talk about?