Use GitHub Releases for all update downloads
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 55/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- github
- Domain
- release
Research direction
Start with version/version.json and trace how the in-app updater uses its current-version downloadInfos entries. Inspect the platform-specific aka.ms redirects and corresponding GitHub Release assets, then verify Windows, macOS, and Linux downloads, SHA-256 checksums, Snap handling, staged rollout, and older-version fallback against the acceptance criteria.
Written by the indexing model from the issue text.
Description
Problem
The current-version entry in version/version.json can omit explicit artifact URLs and fall back to the platform-specific aka.ms/storage-explorer/download/... redirects. Those redirects are backed by Microsoft Download Management Service and ESRP publication, which introduces approval and propagation delays and prevents the Storage Explorer team from directly controlling which binaries the in-app updater retrieves.
Goal
Use GitHub Releases as the authoritative download source throughout the update path so the team controls artifact publication and link targets directly.
Scope
- Point the platform-specific
aka.ms/storage-explorer/download/...redirects at the corresponding GitHub Release assets. - Add explicit GitHub Release asset URLs to the current-version
downloadInfosentries inversion/version.json. - Retain SHA-256 checksum validation for every platform artifact.
- Keep Snap distribution on the Snap Store.
Acceptance criteria
- Each non-Snap platform download resolves to the intended GitHub Release asset.
- The in-app updater downloads and opens the correct Windows, macOS, and Linux artifacts without relying on ESRP or Download Management Service propagation.
- Every downloaded artifact matches the checksum in
version/version.json. - Update discovery, staged rollout, and older-version fallback behavior continue to work.
- Dominant language
- No language data
- Stars
- 452
- Forks
- 92
- Avg merge
- 2h 7m
- Merged PRs (30d)
- 1
Getting set up
We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/AzureStorageExplorer
-
:beetle: regression :copilot: copilot :test_tube: testing
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
microsoft/AzureStorageExplorer#9191 · 1 comment ·
-
Difficulty 2/5 1-2 days Newbie friendliness 76/100
microsoft/AzureStorageExplorer#9186 ·
-
:globe_with_meridians: hard-coded string :globe_with_meridians: localization :test_tube: testing
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
microsoft/AzureStorageExplorer#9152 ·
-
Sign-in errorOpen
Difficulty 4/5 3-5 days Newbie friendliness 45/100
microsoft/AzureStorageExplorer#9206 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
microsoft/AzureStorageExplorer#9204 ·
All issues in microsoft/AzureStorageExplorer
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Wetzel402/Skylite-UX#112 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
fwcd/tree-sitter-kotlin#289 ·
-
awaiting-response backend bug documentation P2 platform/linux qa
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
wildcard/caro#1501 · 2 comments ·
Maintainers usually reply within 4 days
-
documentation good first issue ready-for-triage ready-to-code
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
release-engineering/fbc-update-planner#102 · 3 comments ·
Maintainers usually reply within 5 days