Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

[Feature]: Define Desktop updater behavior across release channels

Aberta
#3,481 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
35/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
rust, tauri
Domínio
desktop, release

Direção de pesquisa

Start by reading .github/workflows/nightly-artifacts.yml and tracing the Desktop updater configuration and version comparison it feeds. Evaluate the proposed channel policies and document the selected behavior, including visibility and channel switching rules. Done means builds do not offer another channel's release solely due to SemVer ordering, including the stated Nightly versus stable example.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

Problem / opportunity
The Nightly desktop build is compiled as the nightly channel, but the current Nightly artifact workflow points its Tauri updater endpoints at the stable latest-v1.json feed because a Nightly updater feed is not published yet. As a result, a Nightly install can offer stable 1.0.6 as an update over 1.0.6-nightly.20261019, even though the Nightly build comes from a commit 128 commits ahead of v1.0.6. Comparing versions across channels makes the older stable code appear newer and can prompt an unintended cross-channel downgrade.

Proposed behavior
Please define the Desktop updater's release-channel policy and make feed selection and version comparison follow it. Possible designs to evaluate:

  • All-channel build: let users choose stable, beta, or nightly updates, with explicit channel-aware version ordering and clear behavior when switching channels.
  • Stable-only build: check only stable releases and never present beta or Nightly builds as updates.
  • Nightly-only build: check only the Nightly feed, so a stable release cannot be offered as an update to a newer Nightly build.

The chosen behavior should make the active channel visible and avoid treating a release from another channel as a newer update solely because of SemVer ordering.

Product surface
Cross-cutting

Details, examples, or constraints
For example, on 1.0.6-nightly.20261019, the updater should not offer stable 1.0.6 as a newer build when its source commit is older. If channel switching is supported, make the switch explicit and define whether moving between channels is an update, downgrade, or reinstall.

Linguagem predominante
Rust
Estrelas
2.3k
Forks
236
Merge médio
6h 51min
PRs com merge (30d)
253

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de GCWing/OpenBitFun

Todas as issues de GCWing/OpenBitFun

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.