hreyes
9214a1feab
Actualizar a 1.1.4 fallaba con "no escribio config\.version tras la actualizacion" aunque el binario nuevo estuviera instalado y corriendo desde la ruta correcta. La causa era el ORDEN dentro de ensure_runtime_layout(): el sello iba al final, detras del re-despliegue de las deps embebidas (7-Zip y ODBC). Al cambiar de version esas deps se re-copian ENTERAS, asi que el sello quedaba por detras de esa copia y del desempaquetado del onefile de ~254 MB con el antivirus escaneando cada archivo. El PANEL se rendia esperandolo y daba por fallida una actualizacion que iba bien. - El sello se escribe lo primero, en cuanto existen las carpetas. Es tambien mas honesto sobre lo que significa —"que binario esta corriendo"—, que es cierto desde que el proceso arranca. El sello de DEPS sigue yendo al final, donde su comentario explica por que: si la copia falla a medias, el proximo arranque reintenta en vez de quedar marcado como al dia. - La version va en la PRIMERA linea del log de arranque. Permite comprobar que binario corre de verdad mirando solo config/logs, sin depender del sello ni del reporte al panel: verificar una actualizacion deja de obligar a creerse lo que diga otro sistema. La prueba nueva observa el estado del sello EN EL MOMENTO en que empieza la copia de deps, no al final, que es la unica forma de fijar el orden. Comprobado que muerde: devolviendo el sello al final falla con `assert None == '1.1.5'`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
9 lines
468 B
Python
9 lines
468 B
Python
"""CloudRestoreAS - Aplicación de restauración automática de bases de datos SQL Server."""
|
|
|
|
# Fuente ÚNICA de la versión. La leen: el spec de PyInstaller (metadatos del .exe),
|
|
# package-release.sh (nombres de artefacto y release.json) y el reporte al PANEL.
|
|
# Formato obligatorio: puntos y números, monotónico creciente — el PANEL compara
|
|
# versiones como tuplas de enteros para detectar si hay una más nueva.
|
|
__version__ = "1.1.5"
|
|
__author__ = "Aduanasoft"
|