Un Release es una fotografía exacta y matemáticamente verificable de un proyecto en un momento dado del tiempo. En software de escritorio, si liberas un código con bugs, envías un parche mañana. En hardware industrial embebido, si un equipo de producción en serie sale de la fábrica con un firmware defectuoso cargado en su microcontrolador, reparar 10,000 unidades instaladas a nivel nacional será una pesadilla logística.
La industria estandarizó el nombrado de versiones mediante tres números: MAJOR.MINOR.PATCH (Ej. v1.0.0).
Nuestro código actual, probado en banco, es candidato a v1.0.0-rc1 (Release Candidate 1). Al aprobarse, se convierte en el v1.0.0 oficial de Producción.
Paso 1: Cambio de Perfil (Debug a Release).
Durante los últimos 300 días, compilaste tu código C usando el flag -O0 (Cero Optimización) para poder usar el Debugger (GDB) y ver línea por línea. Para producción, debes compilar con -O2 (Optimizar para Velocidad) o -Os (Optimizar para Tamaño), y remover todos los símbolos de depuración. El archivo `.bin` final se reducirá a la mitad de su tamaño y el procesador ejecutará los bucles más rápido.
Paso 2: Generación del Hash SHA-256.
Genera el binario (ej. `mobagas_v1_0_0.bin`). Luego, en tu terminal Linux/Mac, ejecuta sha256sum mobagas_v1_0_0.bin. Esto generará una cadena alfanumérica única (Ej. e3b0c44298fc1c149afbf4c8996fb...). Si un solo bit de tu código cambia, este Hash cambiará completamente.
Paso 3: Taggear el Repositorio (Git Annotated Tag).
No crees un branch llamado "Release". Usa un Tag Anotado. Ejecuta: git tag -a v1.0.0 -m "Release Oficial Bare-Metal Tesis Fase 5" y luego git push origin v1.0.0. Esto sella el commit específico para siempre en la historia del repositorio.
En el entorno corporativo, esto lo hace Jenkins o GitHub Actions de forma remota. Nosotros crearemos un script en bash local para tu máquina (Linux/Mac/WSL) que automatizará la construcción del "Paquete de Producción".
#!/bin/bash
# =========================================================================
# build_release.sh - Script de Sellado y Empaquetado de Hardware/Software
# Proyecto: Tesis Despachador Gas LP (Fase 5 - BareMetal)
# =========================================================================
VERSION="v1.0.0-rc1"
RELEASE_DIR="release_out/$VERSION"
FIRMWARE_DIR="./STM32_Firmware"
HARDWARE_DIR="./KiCad_Hardware"
echo "[1/5] Iniciando Empaquetado para Versión: $VERSION"
# Crear directorio de salida limpio
rm -rf "$RELEASE_DIR"
mkdir -p "$RELEASE_DIR"
echo "[2/5] Compilando Firmware (Perfil: RELEASE -O2)..."
cd $FIRMWARE_DIR
make clean
# Compilar forzando optimización extrema (Depende de tu Makefile)
make BUILD_PROFILE=RELEASE OPT="-O2"
# Extraer el binario purgado (Sin símbolos de debug)
arm-none-eabi-objcopy -O binary build/main.elf build/mobagas_firmware.bin
cp build/mobagas_firmware.bin "../$RELEASE_DIR/mobagas_$VERSION.bin"
cd ..
echo "[3/5] Recopilando Gerbers y Lista de Materiales (BOM)..."
# Asumimos que exportaste los Gerbers previamente desde KiCad a una carpeta de ploteo
zip -r "$RELEASE_DIR/pcb_gerbers_$VERSION.zip" "$HARDWARE_DIR/Gerbers/" > /dev/null
cp "$HARDWARE_DIR/bom_production.csv" "$RELEASE_DIR/"
echo "[4/5] Generando Firmas Criptográficas (SHA-256)..."
cd "$RELEASE_DIR"
# Firmar todos los archivos en la carpeta de release
sha256sum * > "checksums_$VERSION.txt"
cd ../..
echo "[5/5] Sellando Repositorio en Git (Annotated Tag)..."
# Solo si el directorio git está limpio
if [ -z "$(git status --porcelain)" ]; then
git tag -a "$VERSION" -m "Release Final Fase 5: Hardware & BareMetal Firmware"
echo " [V] Git Tag $VERSION creado exitosamente."
echo " [!] Ejecuta 'git push origin $VERSION' para subir a GitHub/GitLab."
else
echo " [X] ADVERTENCIA: Tienes cambios sin commitear. El Tag de Git fue omitido."
fi
echo "=================================================================="
echo " PAQUETE DE PRODUCCIÓN LISTO EN: $RELEASE_DIR"
echo "=================================================================="
ls -lh "$RELEASE_DIR"
Objetivo del día: Control de Versiones Estricto (CM) y Congelamiento de Configuración Base.
A lo largo de los últimos 300 días, tu código en lenguaje C (Bare-Metal) creció como un ente orgánico. Escribiste un bucle gigante (`while(1)`) dentro de tu `main.c` que llamaba funciones secuencialmente (Polling). Esa arquitectura fue excelente para depurar, para entender cada sensor, y para validar que la tubería hidráulica y la placa madre PCB funcionaran en el mundo real.
Pero a partir de mañana (Día 309 y el inicio extra-oficial hacia la lógica de la Fase 6), romperemos ese monolito en pedazos y le inyectaremos el kernel de un **Sistema Operativo en Tiempo Real (FreeRTOS)**. Ese cambio es violento y destructivo a nivel de código. Si algo sale mal con la configuración de las tareas del RTOS en el Día 320, o si el procesador falla por un desbordamiento de pila (Stack Overflow), necesitas una **red de seguridad absoluta** a la cual regresar.
Al generar el **Release `v1.0.0-rc1`** de hoy, no solo has aprendido a empaquetar un producto comercialmente; has creado un "Save Point" inmutable en tu Tesis. Si la fábrica de ensamblaje te exige hoy mismo los archivos de producción, tienes un `.zip` firmado criptográficamente con los Gerbers de tu PCB finalizada y el binario funcional del código Bare-Metal. El esqueleto y el sistema nervioso primario de tu máquina están a salvo de la historia.
.bin / .hex), los archivos de fabricación de la placa (Gerbers/BOM), y en algunos casos, notas sobre la versión de la cadena de herramientas (Toolchain/GCC) empleada.-O2 o -Os) y removiendo los símbolos de depuración para maximizar el rendimiento de la CPU y el ahorro de memoria Flash.