Remote: Iteration Plan for March 2020

[kieferrm]

This plan captures our work on the Remote development extensions in March. We follow the same iteration cycle as VS Code. Although we plan for a whole iteration, we not only ship at the end of an iteration but throughout.

Plan Items

Below is a summary of the top level plan items.

Legend of annotations:

Mark	Description
🏃	work in progress
✋	blocked task
💪	stretch goal for this iteration
🔴	missing issue reference
🔵	more investigation required to remove uncertainty
⚫	under discussion within the team

Remote - Core

• 🏃 Can't drag files from a remote vscode window to a local window https://github.com/microsoft/vscode-remote-release/issues/1149 @isidorn

Remote - SSH

• None.

Remote - Containers

• Attach to Kubernetes Attach to Kubernetes #2497 @chrmarti
• Explore WSL2 support for Remote - Containers Explore WSL2 support for Remote - Containers #2498 @chrmarti
• Investigate removing dependency on Dockerode Investigate removing dependency on Dockerode #2481 @chrmarti
• Improve proxy support for remote running containers Do not lookup local proxy when running remote #2487 @chrmarti
• Respect user defined project name Remote-Container (docker-compose) Support for .env and/or COMPOSE_PROJECT_NAME variable #222 @chrmarti
• Investigate improving progress shown when creating a dev container Investigate improving progress shown when creating a dev container #2499 @chrmarti
• Open repository in a Container, offer to create a devContainer.json when it doesn't exist already Repository Container: Offer to create devcontainer.json when it does not exist #1570 @egamma
• Checkout a GitHub PR or branch into a container Allow specifying a branch/tag/PR when for "Open repository in container..." command #2461 @egamma
• New Python 3, 3.6, 3.7, and 3.8 pre-built images and devcontainer.json @Chuxel

Remote - WSL

• None.

---

Deferred Items

• Polish Remote Explorer Header Remote Explorer: when there is only one view, split view should not be present vscode#86037 @alexr00 @misolori
• Explore speeding up container creation by caching extensions locally @sandy081
• Explore using the git installed on Windows remote-wsl: allow some way to use Windows git for git repo #1844 @aeschli

[enjibby]

I have recently received a notification that #222 is now closed. Will the changes for this make it into the March 2020 work's release?

[chrmarti]

@enjibby Yes. (You can also tell by the milestone being set to March.)

[enjibby]

You guys are total legends :)

Edit: tested this in code-insiders and the seemingly-small change to include the .env file from the root of the project to provide environment variables to the docker-compose process makes such a positive difference to my dev workflow!

Thankyou again!

[rawtaz]

Here's a few questions about lacking information:

• This iteration plan was for March 2020. Is it not supposed to be over, and now by the 6th of april a new release containing the changes in this iteration plan having been made?

• If yes, where is that release, which version number did it get?

• In general, where can one find a changelog for the release versions of this extension? Looking at https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers there's no such thing, nor is there any changelog or release notes in this repository.

• And finally, I am running VS Code 1.43.2 (updated yesterday), with all extensions updated (yesterday), and when I hit "Check for Extension Updates" it checks and then tells me everything is up to date. If I instead right-click the "Remote - Containers" extension and select "Install Another version…", the most recent version I'm presented with is 0.106.0, which I already have installed. So, why on earth isn't the on https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers listed version 0.110.0 offered to my VS Code?

There's a severe lack of information on these topics.

[Chuxel]

@rawtaz Thanks for asking for clarifications. These extension follow the VS Code release cycle and planning process. Dates in the the VS Code plan of note:

• March 30th, 2020: Endgame begins
• April 3rd, 2020: Endgame done

Note that, as described here, endgame week is finalizing development, not release week.

We are currently in "week 1" of the next development iteration which is planning, bug debt, and release. The iteration plan is published once the plan is complete and this one will be closed.

For versions, there are two "channels" for updates - stable and insiders. VS Code - Insiders gets extension updates faster than stable. In terms of version numbers, VS Code and each extension has different version numbers. The final version number of the extension is not known until the time of release since updates are made to the extensions throughout the iteration to VS Code Insiders only. This allows people to get access to the latest features when they want, or to wait for the stable release.

Version 0.110 you see is one of these insiders-only releases to allow to allow those that are interested to preview and provide feedback on new features - it is also the candidate release to VS Code stable once the VS Code update happens this week.

An easy way to tell when a stable release has happened is that your version of VS Code itself will update and you'll see release notes appear - including references to the VS Code Remote extensions.

Note that we also ship out-of-band updates to the Remote extensions to stable when critical issues are encountered like the release of 0.51 for Remote - SSH, but we try to avoid this if at all possible.

[rawtaz]

@Chuxel That was a very well written and clear reply. Thanks so much for that great communication! It clears it up quite a bit.

Here are a couple of suggestions I'd like to make which would improve the information to users:

• On the extension details (not just for this one, but in general), please change Version 0.110.0 to something like Version 0.110.0 (insider), 0.106.0 (stable) - this way people will clearly get a hint as to why they might not get the latest (insider) version in their VS Code, and gather more information about it through the next point:

• Preferably also make the text snippets "insider" and "stable" in the previous suggestion link to a page that contains information about the different channels - this way people who don't know about it will see that there's something to click on, and eventually learn about the different channels. The "insider" one could like to e.g. this or this. The "stable" one I'm not sure.

One thing I didn't see answered is where to find a changelog/release notes with what changes were made in each version. It should be easily noticeable and accessible on e.g. the extension's information page (e.g. the one I linked to before), and preferably also in this repository (considering it's specifically about releases of the Remote extension). Can you elaborate?

Finally, wouldn't it be a good idea to just have a setting in VS Code where you can toggle if you want to be on the insider or stable channel (requiring reboot and update of course)?

[Chuxel]

changelog/release notes with what changes were made in each version.

These are in VS Code docs and linked from the main VS Code Release notes. For example, here's the section on VS Code release notes for 1.43 which links to more detailed release notes here.

We do not currently include the extension versions in these release notes since they are quite tied to a VS Code version, but we could do that if that would help.

Wouldn't it be a good idea to just have a setting in VS Code where you can toggle if you want to be on the insider or stable channel

@rawtaz The remote extensions sometimes depend on updates to VS Code itself which is why they are shipped on the same schedule and features are held out of stable until a VS Code release. Note that VS Code stable and insiders can be installed next to each other on the same machine to make it easy to switch between the two.

[rawtaz]

Oh, so.. You pretty much always ship new VS Code versions and new extension versions (for this extension anyway) at the same time? They're not separately released?

Then one will have to practically wait for VS Code updates rather than updates to the individual extensions.

[Chuxel]

@rawtaz Yep, the extensions will update when a new version of VS Code ships.

VS Code stable is roughly every 4 weeks. VS Code Insiders updates daily, so it gets updates more frequently for the remote extensions. That said, VS Code Insiders is what the team itself uses to build the product.