Cliente de escritorio

Instalación

El cliente de escritorio es una aplicación nativa disponible para Windows, macOS (Apple Silicon) y Linux. Los instaladores de Windows, macOS y Linux también incluyen la CLI uversion y la dejan accesible. Descárgalo en /downloads.

Windows

Descarga uVersion_x.y.z_x64-setup.exe (instalador NSIS firmado, ~25 MB). Al ejecutarlo, el instalador:

• Instala el cliente en %LOCALAPPDATA%\uVersion (por usuario, sin necesidad de administrador)
• Añade la carpeta de instalación al PATH de usuario (la CLI uversion.exe viene incluida ahí)
• Crea un acceso directo en el menú de inicio
• Activa la actualización automática mediante el updater de Tauri

Windows en flotas: el MSI

Para desplegar en muchos equipos con una herramienta de gestión de parque (Intune, SCCM, directiva de grupo...), usa el MSI en lugar del instalador NSIS: uVersion_latest_x64_en-US.msi (URL estable, siempre la última versión, ~10 MB). Instalación silenciosa, por máquina:

msiexec /i uVersion_latest_x64_en-US.msi /qn /norestart

• Instala en C:\Program Files\uVersion (requiere permisos de administrador). La CLI uversion.exe se incluye, pero la carpeta no se añade al PATH: si tus usuarios la necesitan en una terminal, haz que la añada la herramienta de despliegue.
• Sin actualización automática en una instalación MSI: el cliente se queda en la versión desplegada y las actualizaciones del parque se hacen redesplegando el MSI siguiente. Es intencionado: el updater integrado instalaría una segunda copia, por usuario, junto a la gestionada.
• Desinstalación silenciosa: msiexec /x uVersion_latest_x64_en-US.msi /qn

En el primer inicio, cada usuario introduce la dirección del servidor y valida la huella del certificado, una vez por usuario y por equipo (ver Huella TLS).

macOS (Apple Silicon)

Descarga uVersion_x.y.z_macos-arm64.app.zip (~32 MB, firmado con Developer ID y notarizado por Apple). Doble clic para descomprimir, luego arrastra uVersion.app a /Applications. En el primer inicio, Gatekeeper valida automáticamente la notarización, sin ninguna advertencia.

La CLI uversion viene incluida dentro de la app. En el primer inicio, el cliente crea automáticamente un enlace simbólico a ~/.local/bin/uversion y añade ~/.local/bin a tu PATH mediante ~/.zprofile: no se requiere ninguna acción manual. Abre una nueva terminal y uversion estará disponible.

Nota: solo se admite Apple Silicon (M1/M2/M3/M4). No hay binario Intel.

Linux

Un único formato para x86_64: el AppImage (uVersion_x.y.z_amd64.AppImage, ~85 MB). Portable, incluye sus dependencias (libwebkit2gtk, libgtk, libsoup, etc.) y funciona en cualquier distribución reciente sin instalación en el sistema. Requisitos: Ubuntu 24.04 o superior, Debian 13 o superior, o una distribución de una generación equivalente. El binario exige una biblioteca C del sistema reciente, y el AppImage no baja ese piso: incluye el entorno gráfico, no la biblioteca C.

La vía recomendada es el script de instalación. Sin sudo:

curl -fSL https://uversion.io/downloads/client/install.sh | sh

No hace nada mágico y, sobre todo, nada que pida permisos:

• se niega a ejecutarse como root, en una arquitectura que no sea x86_64, o en un sistema demasiado antiguo para ejecutar el binario, indicando cuál de los tres es el problema;
• descarga el AppImage en ~/Applications/uVersion.AppImage, comprueba que lo recibido es realmente un ejecutable de Linux (de lo contrario, un portal cautivo o una página de error se guardarían y se harían ejecutables, para fallar más tarde de forma incomprensible), y luego lo coloca en su sitio en un solo gesto, lo que sigue siendo seguro incluso si ya hay una copia en ejecución;
• inicia la aplicación. Es ese arranque el que crea la entrada en el menú de aplicaciones, así que conviene dejarlo hacer. En una sesión remota sin interfaz gráfica, muestra en su lugar el comando exacto que debes escribir desde tu propio escritorio.

También puedes descargar el AppImage a mano desde la página de descarga, hacerlo ejecutable y lanzarlo:

chmod +x uVersion_x.y.z_amd64.AppImage
./uVersion_x.y.z_amd64.AppImage

No hay paquete .deb para el cliente, y no lo habrá: un paquete instalado por dpkg solo puede actualizarse volviendo a pasar por dpkg, es decir, mediante una elevación de privilegios en cada versión, lo cual es imposible en un equipo sin permisos de administrador. El AppImage se reemplaza a sí mismo, sin contraseña. El servidor, en cambio, sí conserva su paquete .deb.

Nota: la CLI uversion viene incluida dentro del AppImage. En el primer inicio, el cliente copia el binario en ~/.local/bin/uversion y añade ~/.local/bin a tu PATH mediante ~/.profile (no se requiere ninguna acción manual). La entrada en el menú de aplicaciones se crea en el primer inicio, por la misma razón: un AppImage es un archivo, no una instalación.

Primer inicio

1. Indicar la dirección del servidor y tus credenciales

En el primer inicio, el cliente muestra la página de login, titulada Welcome to uVersion. El campo Server address no espera una URL completa: está dividido en tres bloques, un prefijo https:// no modificable, la máquina y el puerto (8443 por defecto). El esquema está impuesto, el cliente no puede producir un http://. Pegar una dirección completa o un host:port en la casilla de la máquina lo reparte automáticamente entre los dos campos. A continuación introduce Username y Password, y pulsa Sign in.

2. Verificar la huella del servidor, una sola vez

Como un servidor uVersion está autofirmado por defecto, la primerísima conexión a una máquina dada muestra Verify server identity: compara la huella SHA-256 con la que te ha dado tu administrador, y luego haz clic en Trust this server. La pregunta solo se plantea una vez por servidor, y si vuelve bajo el título rojo Server identity changed, la huella ha cambiado: no aceptes sin verificar. Ver Huella TLS.

Una vez conectado, el cliente recuerda tu sesión de forma segura. La CLI uversion y los plugins de editor (Unreal, Rider) reutilizan automáticamente las mismas credenciales: no vuelves a introducir tu contraseña en ningún otro sitio.

Abrir o clonar un repositorio

Conectarse no abre ningún proyecto: la lista de repositorios se solicita explícitamente. Es la misma ventana la que sirve para clonar un proyecto por primera vez y para reabrir un workspace ya presente en el disco.

1. Abrir la ventana Open Repository

Mientras no haya ninguna pestaña abierta, el Workspace muestra No repository selected y un botón Open Repository. Una vez que tienes al menos una pestaña, la misma pantalla se obtiene con el + de la barra de pestañas. La ventana lista, una tarjeta por proyecto, los repositorios a los que tienes acceso, con un botón Refresh para volver a pedir la lista al servidor.

2. Clonar, o reabrir un workspace existente

Cada tarjeta propone la acción que corresponde a su estado:

• Clone: crea un workspace nuevo. El campo Workspace name de la tarjeta nombra la carpeta creada y toma el nombre del proyecto si se deja vacío. El selector de carpeta que sigue pide la carpeta padre: uVersion crea la subcarpeta por sí mismo.
• Clone New: el mismo botón, renombrado cuando ya existe un workspace para este proyecto. Clonar una segunda vez es legítimo, por ejemplo para mantener dos estados del proyecto uno al lado del otro.
• Open: reabre un workspace ya clonado en esta máquina, cuya ruta se recuerda bajo la tarjeta. Switch to Open Tab aparece en su lugar cuando la pestaña ya está abierta.
• Open Local Repository..., abajo en la ventana: apunta a una carpeta que ya contiene un .uversion/, por ejemplo tras haber movido un workspace.

La casilla Download files after clone, abajo, está marcada por defecto y lanza la descarga justo tras el clon. Desmárcala para crear el workspace ahora y traer los archivos más tarde.

3. Seguir la descarga

La ventana se cierra en cuanto arranca el clon, y es intencionado: la transferencia puede durar horas y no debe bloquearte. El progreso continúa en la cabecera del cliente, la pestaña del workspace se abre sola al final, y un corte de red no pierde nada, ya que la transferencia se reanuda por sí misma.

Workspace

Un workspace es una carpeta local vinculada a un repositorio del servidor. El cliente puede gestionar varios workspaces a la vez, mostrados en la barra de pestañas de arriba. Cada workspace guarda sus metadatos en .uversion/ en la raíz de la carpeta local:

• .uversion/config.toml: el único archivo verdaderamente importante. Su sección [workspace] lleva el propietario del workspace (owner), su identificador, su nombre y last_synced_revision, la revisión con la que estás sincronizado (no existe ningún archivo .last_sync). Ahí es también donde se recuerda la ruta del motor Unreal.
• .uversion/checkouts_<workspace_id>.json: los bloqueos que TÚ tienes en este workspace
• .uversion/changelists_<workspace_id>.json: tus changelists, es decir, paquetes de archivos reservados que agrupas para enviarlos por separado. Puramente local, nunca transmitido al servidor.
• .uversion/pending_deletes_<workspace_id>.json: las eliminaciones pendientes de envío
• .uversion/snapshots.json: el estado conocido de los archivos, que sirve para detectar lo que has modificado localmente

Pestaña Files

Vista en árbol de los archivos del workspace con su estado. Dos maneras de reducir la lista:

• El campo de búsqueda, titulado Search files...: filtra por una parte de la ruta, sin distinguir mayúsculas y minúsculas.
• Los chips de estado, justo debajo. Son contadores en los que se puede hacer clic, y un chip solo aparece si su contador supera cero: en un workspace recién sincronizado, verás por tanto solo {n} synced, y la ausencia de los demás es normal. Los seis chips posibles son {n} synced, {n} modified, {n} local only, {n} server only, {n} locked y {n} deleted.

Búsqueda y chips se combinan: la búsqueda restringe primero, los chips filtran después. La vista se mantiene fluida incluso en proyectos de varias decenas de miles de archivos.

Selección múltiple + acciones

La barra de acciones solo existe si hay algo seleccionado. Mientras la selección está vacía, no hay ningún botón: es normal, no es una carga en curso. Selecciona archivos (clic + shift, o las casillas) y la barra aparece, precedida del número retenido ({n} file(s) selected). Los botones se muestran según lo que permita la selección:

Pestaña Pending

Archivos actualmente en checked-out, locked por ti O por otro usuario. Dos secciones:

• Your locks: puedes hacer checkin, revert o release individualmente
• Other users' locks: ves quién posee el bloqueo + un botón Request release que crea una tarjeta de solicitud en el tablero Production (una insignia request)

Los admins ven además un botón Force unlock en los bloqueos ajenos, que hace release del bloqueo sin el consentimiento del titular. Todos los force unlock se auditan.

Pestaña History

Lista paginada de los commits del repositorio, con autor, fecha, mensaje y archivos modificados. Hacer clic en un commit abre el detalle: la lista completa de los archivos del commit con sus revisiones.

Botón Get all en cada commit para descargar una copia local de todos los archivos en esa revisión (útil para recuperar un estado estable).

Production

La zona Production (una entrada dedicada en la barra lateral) agrupa el seguimiento de proyecto, por repositorio. El Workspace, por su parte, se concentra en los archivos (Files, Pending, History).

My tasks

La lista de tarjetas que se te han asignado, agregada sobre todos los repositorios a los que tienes acceso.

Board

Tablero kanban por repositorio, con columnas configurables (por defecto To Do, In Progress, Review, Done). Cada tarjeta lleva una prioridad (low / normal / high / urgent), etiquetas, asignados, una fecha límite, comentarios, enlaces a assets o commits, y una imagen de portada.

Dashboard

La cabina del productor: una franja de salud del proyecto (bloqueantes abiertos, informes de playtest en espera), las zonas que concentran los problemas, los commits de la semana, el peso del proyecto y la última build publicada, cada bloque remitiendo al tablero o a Games.

Debajo, la línea de tiempo de calendario: hitos, playtests (puntuales o recurrentes), releases y fechas límite de tarjetas. Un playtest recurrente genera automáticamente su tarjeta de tablero en cada ocurrencia.

Watchlist

Vigila rutas (patrones glob) para recibir notificaciones de los check-ins que las tocan. Cada entrada indica la ruta vigilada y los eventos seguidos.

Games

La zona Games lista las builds de playtest internas publicadas para el proyecto. Cada build indica su versión, su configuración (DebugGame / Development / Shipping), su plataforma (Win64 / Mac / Linux), su tamaño y sus notas de versión, con un botón de descarga adaptado a la plataforma.

Es el punto de acceso de los playtesters: una cuenta con el rol playtester solo ve esta página (ni Workspace ni Production), y solo accede a las builds de los proyectos que le están abiertos.

Changelists locales

Agrupa tus checked-out files en varios commits independientes. Las changelists son locales a tu workspace (nunca enviadas al servidor). Útil para:

• Separar un fix crítico de un trabajo en curso
• Preparar varios envíos en paralelo sin mezclarlo todo
• Mantener una changelist "default" para el WIP y una "review" para lo que sale en checkin

Settings

Preferencias globales del cliente (guardadas en %APPDATA%/uversion/uVersion/config/config.toml):

Panel Unreal

Cuando el cliente detecta un proyecto Unreal en el workspace, aparece una barra de acciones dedicada arriba a la derecha del Workspace. Pilota el motor directamente desde el cliente: abrir el editor, compilar, empaquetar, sin pasar por un IDE. La mayoría de las acciones solo conciernen a los proyectos C++ (un proyecto Blueprint puro no necesita compilar).

La pastilla de estado del plugin

Del todo a la izquierda de la barra, una pastilla indica en qué punto está el plugin Unreal para este proyecto. Es cliqueable:

Ruta del motor

La ruta de instalación de Unreal se resuelve automáticamente a partir del EngineAssociation del .uproject (registro de Windows, LauncherInstalled.dat, o build de fuentes). Esta ruta es necesaria para todas las acciones de abajo, y la resolución automática falla en particular con un motor compilado desde las fuentes. Aquí es donde ajustarla a mano.

1. Abrir el menú de acciones secundarias

No hay ni campo de entrada, ni botón Browse, ni botón Auto-detect visible en la barra. El único punto de entrada es el botón en forma de engranaje, del todo a la derecha de la barra Unreal, acompañado de un pequeño chevrón y cuyo tooltip dice More actions. Nada en su aspecto habla del motor, y por eso no se encuentra.

2. Elegir Set Engine Path...

La entrada Set Engine Path... es la última del menú. Su subtítulo muestra la ruta actual, o Not configured si no hay ninguna: es la forma más rápida de saber si el problema viene de ahí. Se abre un selector de carpeta, y la ruta elegida se guarda en el .uversion/config.toml del workspace.

Open Editor

Lanza el editor Unreal (UnrealEditor) sobre el proyecto del workspace. El botón es idempotente: el editor puede tardar varias decenas de segundos en mostrar su ventana (sobre todo en macOS / Linux), así que un segundo clic durante ese tiempo no abre una segunda instancia. El botón muestra «Opening…» mientras el editor se lanza. Para un proyecto C++ nunca compilado localmente, abrir el editor dispara primero una generación de los archivos de proyecto y luego una compilación (ver Acciones automáticas).

Compile

Compila el proyecto (Unreal Build Tool). La salida se muestra en tiempo real en una consola integrada. Un proyecto C++ debe compilarse para que el editor pueda abrirlo y para reflejar los cambios de código.

Sync y Status

Estos dos botones viven en la misma barra, y no en la pestaña Files:

• Sync: actualiza todo el workspace desde el servidor. Su tooltip indica el número de archivos en espera cuando los hay. Es el verdadero «sync» del cliente, que no hay que confundir con el botón Download de la pestaña Files, que solo trae la selección.
• Status: refresca el estado del lado del servidor, bloqueos de otros usuarios incluidos, y vuelve a actualizar el contador del botón Sync.

El menú More actions

Las acciones menos frecuentes se agrupan tras el botón en forma de engranaje, a la derecha de la barra (captura de arriba):

• Generate Project Files: regenera los archivos de proyecto del IDE (Visual Studio, Rider). Útil tras haber añadido o eliminado archivos fuente, o tras un clon.
• Publish Editor Binaries: compila y luego publica los binarios de editor correspondientes al último commit de código. Tus compañeros los recuperan en el sync en lugar de recompilar cada uno por su lado. Ausente en Linux.
• Force Sync: vuelve a descargar sobrescribiendo tus archivos locales. Señalado en rojo en el menú, con la mención overwrites local, y precedido de una confirmación. A reservar para los workspaces que uno acepta perder.
• Set Engine Path...: el ajuste de la ruta del motor, descrito más arriba.

Package

El botón se llama Package; «Package Game» no es más que su tooltip, reemplazado por Set Engine Path first cuando falta la ruta del motor, quedando entonces el botón desactivado. Empaqueta el juego mediante RunUAT BuildCookRun y archiva el resultado en Packages/{config}/ en la raíz del workspace. Tres configuraciones a elegir:

La carpeta Packages/ se ignora por defecto (.uversionignore): los empaquetados no se versionan, se distribuyen mediante Publish Build.

Publish Build

Publica una build empaquetada como versión de playtest interna. Pasa a ser descargable por tu equipo desde la página Games del cliente (rol playtester o acceso a la build concedido). El cliente escanea Packages/{config}/, envía los archivos (deduplicados del lado del servidor) y luego registra el manifiesto.

Open project folder

Abre la carpeta del workspace en el explorador de archivos del sistema (Explorador de Windows, Finder, o xdg-open en Linux).

Stop

Interrumpe limpiamente todas las builds en curso: compilación y empaquetado. El botón indica cuántas builds se han detenido (una compilación automática lanzada en segundo plano puede contarse con ellas).

Acciones automáticas

Además de los botones, el cliente dispara ciertas acciones Unreal por sí solo, para que un proyecto C++ permanezca siempre al día y compilable:

• Antes de un check-in: si han cambiado archivos de código, el proyecto se compila primero. Si la compilación falla, el check-in queda bloqueado (no se envía código que no compila).
• Después de un sync: si el sync ha descargado código, el cliente regenera los archivos de proyecto y luego recompila.
• En el primer inicio tras un clon (proyecto C++): generación de los archivos de proyecto y luego compilación, antes de poder abrir el editor.

Estas builds automáticas se serializan sobre el bloqueo del motor (Unreal Build Tool -WaitMutex): no se rechazan entre sí, se encadenan. El botón Stop también las interrumpe.