Actualizar a RaiSE 3.1.0¶
Esta guia es el como. Para que cambio y por que, ver las notas de release 3.1.0.
Estas en un release candidate? No corras rai self-update
En todos los release candidates de 3.1.0, rai self-update borra
~/.local/bin y todo lo que hay dentro -- el symlink de rai y cualquier
herramienta ajena que guardes ahi -- y elimina su propio respaldo en la misma
operacion, asi que no queda nada recuperable.
Publicar 3.1.0 hace que tres superficies te ofrezcan exactamente ese
comando: el prompt de rai session start, tu agente siguiendo su skill de
inicio de sesion, y el fix hint de rai doctor. Rechaza las tres.
Actualiza con el instalador -- ruta B.
1. Cual es tu ruta?¶
Corre los dos comandos:
| Lo que ves | Estas en | Ruta |
|---|---|---|
self-upgrade existe |
ya en 3.1.0 o posterior | A |
No existe el comando; rai es un symlink a ~/.local/share/rai/ |
un release candidate | B |
No existe el comando; rai esta bajo .venv/, pipx o uv tool |
2.x, 3.0.x, o un beta de 3.1.0 | C |
rai: command not found |
nada instalado | Guia de instalacion |
Todas las rutas terminan en la misma lista.
2. Primero, respalda la base de datos¶
La migracion de schema es solo hacia adelante y corre en el primer open de la
base de datos -- incluidos comandos de solo lectura como rai db status. Una
vez que corrio, ningun binario anterior puede volver a abrir el archivo.
3. Tu ruta¶
Ruta A -- cuando rai self-upgrade ya existe¶
Estas en 3.1.0 o posterior, asi que la capa de paquete ya trae la correccion. Este es el camino normal de aqui en adelante: actualiza primero el binario y despues los archivos de gobernanza del proyecto actual.
Solo toca el proyecto desde el que lo corres. Corre rai upgrade en cada otro
checkout -- la primera linea de la lista.
Ruta B -- desde un release candidate¶
Actualiza con el instalador. Es un camino de codigo distinto de
rai self-update: reemplaza los bundles privados bajo ~/.local/share/ y
despues rehace los symlinks, y nunca trata ~/.local/bin como un directorio a
intercambiar -- que es lo que hacia el defecto del release candidate.
El instalador de Windows es igual de seguro sobre un release candidate: limpia el
directorio de instalacion antes de copiar, asi que no sobrevive metadata
obsoleta que haga a rai --version reportar el build equivocado.
Para fijar un build exacto o revisar el script antes, ver la guia de instalacion.
Si rai self-update ya destruyo ~/.local/bin
Volver a correr el instalador restaura rai y rai-mcp-pipeline. No
restaura nada mas de lo que vivia ahi -- otras herramientas y shims hay que
reinstalarlos a mano.
Despues sigue con la lista.
Ruta C -- desde venv, pip, pipx o uv tool¶
Tu actualizacion es una migracion: cambia el metodo de instalacion mismo, y hay residuos que remover antes de que el binario nuevo se comporte. La guia de migracion venv a binario es el procedimiento completo y ya contiene la lista de abajo -- siguela de principio a fin.
Si vienes de 2.x, lee primero la
guia de migracion desde 2.x, y no te saltes
rai db import-legacy: los archivos de patrones de 2.x no migran solos y se
pierden en silencio.
Te quedas en pip o uv tool en lugar de pasar al binario? Las releases estables
vienen de PyPI y las prereleases solo del registro de prereleases, asi que un
index de prerelease fijado ya no resuelve lo que quieres. Los comandos exactos
estan en la guia de instalacion.
4. Despues del binario -- la lista¶
El instalador y rai self-upgrade mueven el binario. Esto es lo que nada mueve
por ti.
| Haz esto | Donde | Por que |
|---|---|---|
rai upgrade |
cada checkout | Skills, .raise/ y AGENTS.md. La ruta A ya hizo el proyecto desde el que la corriste. |
rai graph build |
cada checkout y worktree | El grafo es por checkout en 3.1, y las columnas nuevas solo se pueblan con un build. |
rai memory ingest --apply |
una vez | La memoria Tier-2 no es automatica. Sin esto, las notas demovidas salen del indice y no son recuperables. |
rai db import-legacy |
una vez, solo desde 2.x o 3.0 | Idempotente; los originales se renombran *.migrated, nunca se borran. |
| Reinicia la sesion de tu agente | una vez | El servidor MCP conserva el binario anterior en memoria aunque rai --version ya reporte el nuevo. |
Despues verifica:
Si which rai no imprime tu binario global, tienes shadowing de PATH -- ver
PATH shadowing.
Revisa tus scripts y tu CI
Cuatro cambios de comando en 3.1.0 pueden romper automatizacion que
funcionaba antes: rai init ya no escribe sin --apply, se eliminaron cinco
comandos de rai scm, rai db migrate se renombro, y rai clean ahora
escanea por defecto todos los proyectos registrados. Ver
Cambios de comandos que rompen scripts
en las notas de release.
5. Si necesitas volver atras¶
El binario se revierte; la base de datos no. Ambos son a nivel de maquina — un solo binario y una sola base de datos sirven a todos tus proyectos. Revertir para arreglar un solo proyecto afecta a todos los proyectos de la maquina. Consulta Rollback y Recuperacion para la explicacion arquitectonica completa y estrategias de mitigacion por proyecto.
curl -fsSL https://github.com/humansys/raise/releases/latest/download/install.sh | bash -s -- --version <version-anterior>
La migracion de schema es solo hacia adelante — un binario mas viejo abriendo una base ya migrada no esta soportado. Para volver realmente a un build anterior tambien tienes que restaurar el respaldo de la seccion 2:
Todo lo registrado despues de la actualizacion se pierde en esa restauracion —
en todos los proyectos, no solo en el problematico. Por eso el respaldo es el
primer paso — y recuerda que cualquier release candidate al que vuelvas sigue
cargando el defecto de rai self-update descrito al principio de esta pagina.