Você escreve um arquivo de texto que diz de onde seu programa é baixado e quais passos instalam ele, faz commit no seu repositório, e está publicado. Sem conta, sem revisão, sem nomes reservados.
Ela não leva seu software dentro: diz de onde tirar ele e o que fazer com ele em cada sistema operacional. Fica no seu repositório, do lado do código e do pipeline que você já tem.
arrow.yaml na raiz do repositório, ou ARROW.md com a Arrow dentro de um bloco de código arrow. Se você quiser várias num mesmo repositório, elas são agrupadas numa coleção.
Nome, descrição e licença. Não existe campo de versão, e isso é de propósito: quem põe a versão é o git.
Uma receita por plataforma dentro do mesmo arquivo. As chaves são padrões: linux/amd64, windows/*, ou * pra todas. Um target pode herdar de outro, e aquele que declara uma fase fica com ela inteira.
Até cinco fases: install, update, execute, stop e uninstall. Se nenhum target declara execute, sua Arrow é um programa que se instala; se todos declaram, é um serviço que roda.
Os passos de cada fase, em ordem. run roda um comando, fetch baixa um arquivo e pode conferir o hash, signal desliga um processo. Cada passo leva seu título, seu timeout e se aborta quando falha.
variables gera o formulário que o usuário preenche antes de instalar, com tipos, valores padrão e validação. netbridge declara as portas que seu software precisa, e o Quiver atribui e tenta abrir elas no roteador. Um servidor vira tão instalável quanto um editor de texto.
tools são Arrows que precisam estar instaladas antes da sua; services, Arrows que precisam estar rodando enquanto a sua executa. Com exports, uma dependência publica um caminho com nome e você usa ele sem adivinhar onde foi parar.
20 linhas, e um aplicativo está publicado.
Não existe comando de publicação porque não tem onde publicar. O arquivo fica no seu repositório, e esse é o mecanismo inteiro.
Sem cadastro, sem revisão e sem nomes reservados. Dois desenvolvedores não podem reivindicar o mesmo nome porque o nome é o repositório.
Sua Arrow se instala pelo endereço dela: github.com/usuario/repositorio. Não é uma entrada num registro, é a instrução de ir naquele domínio, naquele usuário, naquele repositório e procurar o manifesto ali. GitHub, GitLab, Bitbucket ou a forge que você usar.
É a tag do git de onde o arquivo foi lido: github.com/usuario/repositorio@v1.2.3. Sem tag, o Quiver resolve o último release estável e ignora as pré-releases.
Marque o repositório com quiver-arrow pela interface do seu provedor e ele aparece na busca. Sem a marcação instala igual, pelo namespace: a busca filtra, não autoriza.
Publicar uma versão nova continua dentro do fluxo que você já tem.
O que você escreveu uma vez é executado por um daemon na máquina de quem instala, no Linux, no macOS e no Windows.
quiver install github.com/usuario/repositorio no terminal, ou o mesmo namespace pelo app de desktop, que já vem com o daemon dentro.
O Quiver compila seu manifesto antes de rodar e mostra a lista exata de passos, com os comandos, as URLs e as permissões que pedem. É texto puro, versionado e diffável contra a versão anterior.
Se sua Arrow depende de outras, elas são resolvidas e instaladas antes, como mais um passo na barra de progresso. Duas versões da mesma Arrow convivem em vez de negociar.
Uma tag nova é um release novo. Uma atualização que falha volta ao estado anterior, então nunca quebra uma instalação que já funcionava.
Você escreve o arquivo, faz commit, e já dá pra instalar. Ninguém precisa aprovar.
O formato do manifesto está especificado no repositório do daemon, com o esquema e as regras de validação.