Releases com contrato explicito
O backend classifica o artefato, define installer_type e install_support_level e o SDK executa so o que a release realmente suporta.
Comece por Electron, publique com contrato explicito de update, separe staging e production e acompanhe crashes sem montar uma pilha propria para operacao de desktop.
{
"channel": "stable",
"version": "1.4.2",
"installer_type": "nsis",
"install_support_level": "fully_managed",
"mandatory": false,
"download_url": "signed://release"
}Comece por Electron, use Python quando fizer sentido e deixe .NET, Tauri e Flutter como expansao de produto, nao como promessa pronta.
O ponto central do ShipIO nao e "baixar arquivo". E manter o contrato entre backend, dashboard e SDK claro o suficiente para voce saber quando existe auto update real, handoff de instalador ou fluxo manual.
O backend classifica o artefato, define installer_type e install_support_level e o SDK executa so o que a release realmente suporta.
Capture erro fatal, reenvie no proximo startup e acompanhe stack hash no mesmo lugar em que voce opera release e rollout.
Separe staging e production com releases, crashes e API keys independentes para nao misturar teste, rollout e operacao real.
Comece por Electron com uma superficie ativa hoje. Python segue disponivel, e outras stacks entram sem promessa vazia.
Sessao com refresh token em cookie HttpOnly, links assinados para release e rotacao de chave direto no dashboard.
Plano, limites e modos read-only aparecem no produto para evitar a zona cinzenta entre comercial, permissao e runtime.
O ShipIO entra por Electron porque e onde a dor costuma ser mais clara, mais buscavel e mais cara quando a operacao de release fica improvisada.
Cadastre o app no dashboard e configure os environments que vao receber release, crash e membros.
Comece pela superficie mais forte hoje. Python segue ativo, e .NET, Tauri e Flutter ficam no roadmap publico.
O upload confirma metadados de instalador e publica a versao no canal certo sem depender de inferencia frouxa.
Acompanhe crashes, rollouts, canais ativos e ambiente atual sem trocar de ferramenta.
Campos como installer_type e install_support_level deixam de ser nota de rodape e passam a guiar o que o SDK pode prometer.
Se voce precisa separar ambientes, monitorar crash, rotacionar API key e manter a promessa certa para cada instalador, a proposta faz sentido, especialmente em apps Electron.
Para quem distribui instalador real e nao quer prometer auto update onde o artefato nao sustenta a promessa.
Para quem precisa publicar release e observar crash sem manter servidor de update, links assinados e painel separado.
Para quem precisa separar staging e production, rotacionar chave e limitar mutacao quando billing entra em read-only.
O roadmap abaixo mostra o que ja esta solido, o que vem em seguida e como o ShipIO expande alem de Electron sem diluir a mensagem do produto.
Electron como entrada principal e Python como superficie ativa
Environments por app com chaves independentes
Contract-based updates com installer_type e support level
Crash reporting e operacao no dashboard
.NET, Tauri e Flutter no roadmap oficial
Feature flags para habilitar e desabilitar funcoes por app e environment
Melhor segmentacao de rollout para publicos diferentes
Mais controle operacional sem espalhar configuracao entre ferramentas
Observabilidade de adocao, update aplicado e handoff concluido
Automacoes operacionais de release e rollout
Segmentacao avancada por canal, cohort e contexto de instalacao
Camada mais forte de governanca para desktop delivery em equipes maiores
O dashboard ja tem overview, versoes, crashes, integracao, access, environments, billing e docs. Falta a sua primeira release.