Escribís un archivo de texto que dice de dónde se baja tu programa y qué pasos hay que dar para instalarlo, lo commiteás a tu repositorio, y ya está publicado. Sin cuenta, sin revisión, sin nombres reservados.
No lleva tu software adentro: dice de dónde sacarlo y qué hacer con él en cada sistema operativo. Vive en tu repositorio, al lado del código y del pipeline que ya tenés.
arrow.yaml en la raíz del repositorio, o ARROW.md con la Arrow adentro de un bloque de código arrow. Si querés varias en un mismo repositorio, se agrupan en una colección.
Nombre, descripción y licencia. No hay campo de versión, y es a propósito: la versión la pone git.
Una receta por plataforma dentro del mismo archivo. Las claves son patrones: linux/amd64, windows/*, o * para todas. Un target puede heredar de otro, y el que declara una fase se la queda entera.
Hasta cinco fases: install, update, execute, stop y uninstall. Si ningún target declara execute, tu Arrow es un programa que se instala; si todos lo declaran, es un servicio que corre.
Los pasos de cada fase, en orden. run corre un comando, fetch baja un archivo y puede comparar su hash, signal apaga un proceso. Cada paso lleva su título, su timeout y si aborta cuando falla.
variables genera el formulario que el usuario completa antes de instalar, con tipos, valores por defecto y validación. netbridge declara los puertos que tu software necesita, y Quiver los asigna y trata de abrirlos en el router. Un servidor se vuelve tan instalable como un editor de texto.
tools son Arrows que tienen que estar instaladas antes que la tuya; services, Arrows que tienen que estar corriendo mientras la tuya ejecuta. Con exports, una dependencia publica una ruta con nombre y vos la usás sin adivinar dónde quedó.
20 líneas, y es una aplicación publicada.
No hay comando de publicación porque no hay dónde publicar. El archivo queda en tu repositorio, y ese es todo el mecanismo.
No hay registro, no hay revisión y no hay nombres reservados. Dos desarrolladores no pueden reclamar el mismo nombre porque el nombre es el repositorio.
Tu Arrow se instala por su dirección: github.com/usuario/repositorio. No es una entrada en un registro, es la instrucción de ir a ese dominio, a ese usuario, a ese repositorio y buscar ahí el manifiesto. GitHub, GitLab, Bitbucket o el forge que uses.
Es el tag de git desde el que se leyó el archivo: github.com/usuario/repositorio@v1.2.3. Sin tag, Quiver resuelve el último release estable e ignora las pre-releases.
Etiquetá el repositorio como quiver-arrow desde la interfaz de tu proveedor y aparece en la búsqueda. Sin la etiqueta se instala igual, por namespace: la búsqueda filtra, no habilita.
Publicar una versión nueva es parte del flujo que ya tenés.
Lo que escribiste una vez lo ejecuta un daemon en la máquina de quien instala, en Linux, macOS y Windows.
quiver install github.com/usuario/repositorio en la terminal, o el mismo namespace desde la app de escritorio, que trae el daemon adentro.
Quiver compila tu manifiesto antes de correrlo y muestra la lista exacta de pasos, con sus comandos, sus URLs y los permisos que piden. Es texto plano, versionado y diffeable contra la versión anterior.
Si tu Arrow depende de otras, se resuelven y se instalan antes, como un paso más de la barra de progreso. Dos versiones de la misma Arrow conviven en vez de negociar.
Un tag nuevo es un release nuevo. Una actualización que falla vuelve al estado anterior, así que nunca rompe una instalación que ya andaba.
Escribís el archivo, hacés commit, y ya se puede instalar. Nadie tiene que aprobarlo.
El formato del manifiesto está especificado en el repositorio del daemon, con su esquema y sus reglas de validación.