starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-07-08 18:16:28 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Feature Request: Add Auto-Update feature for an Insiders edition for Terminal #2730

New Issue
Closed
opened 2026-01-30 23:03:26 +00:00 by claunia · 9 comments
claunia commented 2026-01-30 23:03:26 +00:00
Owner
Copy Link

Originally created by @WSLUser on GitHub (Jul 12, 2019).

Summary of the new feature/enhancement

I would like to see an Insiders edition made that updates daily like VSCode. Otherwise a model similar to MS Edge and VS Code extensions: Monthly: stable, beta: weekly, and alpha: daily.

If not updating from the Store (preferably it wouldn't matter), being able to get changes from either clicking "Update" (manual update) or automatically updating (configurable in settings) would be highly desired. ConEmu has this feature and it's great but I'd prefer Windows Terminal.

Proposed technical implementation details (optional)

ConEmu has it going directly to the github release page. This would probably be best for Windows Terminal as well. We don't have a stable yet but alpha can be auto-built binaries created daily at midnight EST or whatever time the Console team feels is appropriate. Beta would be auto-built binaries made weekly. These auto-built binaries would have a summary listing all PRs (which you could click on and examine yourself if desired) that were made since the last binary. An auto-delete feature would need to be in place for daily binaries to prevent the list from getting too long. Basically once a new binary was built, the previous one would be deleted (with some checks ensuring the build was successful and can be run and logic checking if no PRs were made that day, then don't create a new build).

A clear and concise description of what you want to happen.

In the About dialog or in the new settings UI that's getting built, provide an option to update with a "Check for updates" option. A setting for automatically checking and installing updates if available.

Originally created by @WSLUser on GitHub (Jul 12, 2019). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> # Summary of the new feature/enhancement I would like to see an Insiders edition made that updates daily like VSCode. Otherwise a model similar to MS Edge and VS Code extensions: Monthly: stable, beta: weekly, and alpha: daily. <!-- A clear and concise description of what the problem is that the new feature would solve. Describe why and how a user would use this new functionality (if applicable). --> If not updating from the Store (preferably it wouldn't matter), being able to get changes from either clicking "Update" (manual update) or automatically updating (configurable in settings) would be highly desired. ConEmu has this feature and it's great but I'd prefer Windows Terminal. # Proposed technical implementation details (optional) ConEmu has it going directly to the github release page. This would probably be best for Windows Terminal as well. We don't have a stable yet but alpha can be auto-built binaries created daily at midnight EST or whatever time the Console team feels is appropriate. Beta would be auto-built binaries made weekly. These auto-built binaries would have a summary listing all PRs (which you could click on and examine yourself if desired) that were made since the last binary. An auto-delete feature would need to be in place for daily binaries to prevent the list from getting too long. Basically once a new binary was built, the previous one would be deleted (with some checks ensuring the build was successful and can be run and logic checking if no PRs were made that day, then don't create a new build). # A clear and concise description of what you want to happen. In the About dialog or in the new settings UI that's getting built, provide an option to update with a "Check for updates" option. A setting for automatically checking and installing updates if available.
claunia commented 2026-01-30 23:03:28 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Jul 12, 2019):

To provide incentive: https://github.com/microsoft/terminal/issues/279#issuecomment-439179675

In our team's ideal world, you would all be running the latest console bits everywhere everytime we make a change. But that's just not how it is today.

You can do this for Terminal unlike Console.

@WSLUser commented on GitHub (Jul 12, 2019): To provide incentive: https://github.com/microsoft/terminal/issues/279#issuecomment-439179675 > In our team's ideal world, you would all be running the latest console bits everywhere everytime we make a change. But that's just not how it is today. You can do this for Terminal unlike Console.
claunia commented 2026-01-30 23:03:28 +00:00
Author
Owner
Copy Link

@pingzing commented on GitHub (Jul 13, 2019):

To add to this a bit, an MVP for public nightly builds could use the new auto-update for sideloaded apps feature. You basically just stick your .appx (and dependencies) at a URL somewhere, and stuff that URL into the appxmanifest.

@pingzing commented on GitHub (Jul 13, 2019): To add to this a bit, an MVP for public nightly builds could use the new [auto-update for sideloaded apps feature](https://blogs.msdn.microsoft.com/appconsult/2018/03/22/handling-auto-updates-for-sideloaded-uwp-and-desktop-bridge-apps/). You basically just stick your .appx (and dependencies) at a URL somewhere, and stuff that URL into the appxmanifest.
claunia commented 2026-01-30 23:03:28 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Jul 13, 2019):

msix will work with this as well. Also App Installer won't be available on the earliest builds of Win 10 (and Win 7/8.1 from what I've seen in recent PRs from external contributors). The Github release page has a URL and makes it so you could manually install offline as well. That also then brings the possibility of a Chocolately package being created as well for those who prefer updates from Chocolately. The Win32-OpenSSH binary on their Release page is packaged up in a Chocolately package and sure beats manually updating it.

@WSLUser commented on GitHub (Jul 13, 2019): msix will work with this as well. Also App Installer won't be available on the earliest builds of Win 10 (and Win 7/8.1 from what I've seen in recent PRs from external contributors). The Github release page has a URL and makes it so you could manually install offline as well. That also then brings the possibility of a Chocolately package being created as well for those who prefer updates from Chocolately. The Win32-OpenSSH binary on their Release page is packaged up in a Chocolately package and sure beats manually updating it.
claunia commented 2026-01-30 23:03:28 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Jul 22, 2019):

@zadjii-msft any estimate on when this can be looked at?

@WSLUser commented on GitHub (Jul 22, 2019): @zadjii-msft any estimate on when this can be looked at?
claunia commented 2026-01-30 23:03:28 +00:00
Author
Owner
Copy Link

@oising commented on GitHub (Jul 22, 2019):

@WSLUser anybody can look at this, not just Microsoft staff. Open source! Wouldn't you rather they be working on advancing the terminal instead of screwing around with auto updates, just so they can create an entirely new stream of complaints? Someone in the community should take ownership of this.

This is the kind of feature that gets added - perhaps - when a deliverable is in the mid to late beta phase. Windows Terminal is barely out of the starting gate for an early alpha. It's still in flux. A lot of flux.

@oising commented on GitHub (Jul 22, 2019): @WSLUser anybody can look at this, not just Microsoft staff. Open source! Wouldn't you rather they be working on advancing the terminal instead of screwing around with auto updates, just so they can create an entirely new stream of complaints? Someone in the community should take ownership of this. This is the kind of feature that gets added - perhaps - when a deliverable is in the mid to late beta phase. Windows Terminal is barely out of the starting gate for an early alpha. It's still in flux. A lot of flux.
claunia commented 2026-01-30 23:03:29 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Jul 22, 2019):

Yes and this would help with testing all the flux. I’m not much of a C programmer or I’d take a crack at it. I agree anybody could look at this. Just want to be sure it isn’t one of those issues that slips through the cracks.

@WSLUser commented on GitHub (Jul 22, 2019): Yes and this would help with testing all the flux. I’m not much of a C programmer or I’d take a crack at it. I agree anybody could look at this. Just want to be sure it isn’t one of those issues that slips through the cracks.
claunia commented 2026-01-30 23:03:29 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 22, 2019):

There is just about 0% chance this happens before 1.0. There's currently 128 open issues that we've marked for 1.0, and I'm sure there's plenty more that we haven't tracked properly yet. At the moment we're focusing on flushing out and polishing the terminal experience it is. Building and maintaining an auto-updater would detract from that work, and unfortunately none of us have any experience doing that, so it'll take extra long to make sure we research the options and deploy the correct one.

Now, if the community wanted to hop on and lend their expertise, that would certainly be appreciated.

@zadjii-msft commented on GitHub (Jul 22, 2019): There is just about 0% chance this happens before 1.0. There's currently 128 open issues that we've marked for 1.0, and I'm sure there's plenty more that we haven't tracked properly yet. At the moment we're focusing on flushing out and polishing the terminal experience it is. Building and maintaining an auto-updater would detract from that work, and unfortunately none of us have any experience doing that, so it'll take extra long to make sure we research the options and deploy the correct one. Now, if the community wanted to hop on and lend their expertise, that would certainly be appreciated.
claunia commented 2026-01-30 23:03:29 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jul 22, 2019):

Couple things here. Our target for v1.0 is distribution primarily via the store. The store provides both "automatic updating" and gated flight rings for insiders to join. I know it's not ideal for a subset of the population, but we've made this choice to focus our engineering efforts.

We'll re-evaluate this in the future. For now, I'm going to close this one out.

Thanks everything.

@DHowett-MSFT commented on GitHub (Jul 22, 2019): Couple things here. Our target for v1.0 is distribution primarily via the store. The store provides both "automatic updating" _and_ gated flight rings for insiders to join. I know it's not ideal for a subset of the population, but we've made this choice to focus our engineering efforts. We'll re-evaluate this in the future. For now, I'm going to close this one out. Thanks everything.
claunia commented 2026-01-30 23:03:29 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Jul 22, 2019):

So currently, the biggest hurdle is getting CD from Azure Pipelines. You already run CI for checking PRs. Understanding how there are many other competing priorities that take precedent is understandable. Half of this challenge is simply in getting updates to the Release page more frequently. Once that's done, somebody could come in and do the other half of the work to have it do a check against the Release page and if the commits don't match, download and update the existing installation. All you guys need to do is set up CD so that it produces an msix that is then posted to the Release page of this repo. Then configure it to do it automatically every few days and clean up the previous version if possible. If not, then it can be dealt with later. I don't think the setting up of the deployment on an interval should take too much time and effort within Azure Pipelines. Can you guys look at that at least?

@WSLUser commented on GitHub (Jul 22, 2019): So currently, the biggest hurdle is getting CD from Azure Pipelines. You already run CI for checking PRs. Understanding how there are many other competing priorities that take precedent is understandable. Half of this challenge is simply in getting updates to the Release page more frequently. Once that's done, somebody could come in and do the other half of the work to have it do a check against the Release page and if the commits don't match, download and update the existing installation. All you guys need to do is set up CD so that it produces an msix that is then posted to the Release page of this repo. Then configure it to do it automatically every few days and clean up the previous version if possible. If not, then it can be dealt with later. I don't think the setting up of the deployment on an interval should take too much time and effort within Azure Pipelines. Can you guys look at that at least?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Build Help Wanted Issue-Feature Product-Terminal Resolution-Won't-Fix
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#2730
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?