pnpm publicó el 26 de agosto la versión 12.0.0 estable tras un mes de candidatas, Kubernetes estrenó la 1.37 "Garhwal" con dieciséis funciones nuevas en estable y un desacuerdo sobre sus cambios de ruptura, HashiCorp lanzó Terraform 1.16 con datos persistentes de proveedores, Cloudflare workerd llegó a dieciséis días consecutivos de lanzamientos, personaje de la semana en esta sección, GitHub Copilot CLI sumó autenticación de Windows para servidores MCP empresariales, y Next.js reactivó en su rama canary la optimización de imágenes AVIF tras el parche de libheif.
El equipo de pnpm publicó, el 26 de agosto de 2026 a las 15:13 UTC, la versión 12.0.0 del gestor de paquetes, según el registro oficial de lanzamientos del proyecto en GitHub. La versión estable conserva los cambios de ruptura que esta sección documentó a lo largo de agosto: las dependencias de Git alojadas en GitHub, GitLab o Bitbucket se resuelven siempre a través de URLs HTTPS canónicas, sin importar si el manifiesto original usaba "github:owner/repo", una URL SSH o una URL HTTPS explícita; las configuraciones no reconocidas en pnpm-workspace.yaml generan un error con sugerencias de corrección en lugar de ignorarse en silencio; y la resolución de ciclos entre dependencias de pares (peer) sigue ahora un orden canónico que produce lockfiles idénticos byte a byte sin importar el orden de instalación, según el mismo registro de cambios. La versión también estrena funciones: el ajuste globalShims permite que los binarios instalados de forma global respeten las versiones fijadas por cada proyecto, pnpm puede instalar y fijar versión de otros gestores de paquetes -npm, cualquier versión de Yarn y Bun- dentro del mismo flujo de trabajo, y en Linux el método de importación automático prioriza los enlaces duros (hardlinks) sobre la clonación de archivos para acelerar la materialización de node_modules. Que la versión 12 llegue a estable apenas diecinueve días después de la rc.1 del 7 de agosto, con once candidatas de por medio, contrasta con el ritmo de Prisma, que esta sección viene documentando desde esa misma fecha: la versión 8 del ORM competidor sigue en su octava candidata sin fecha de estable, todavía renombrando métodos centrales de su API. La información de esta nota proviene únicamente del registro oficial de lanzamientos de pnpm en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de pnpm, pero el gestor de paquetes gana terreno entre equipos locales de JavaScript que buscan instalaciones más rápidas que npm, para quienes la versión 12 estable ya no exige tratar los cambios de resolución de Git y de pnpm-workspace.yaml como vista previa: la migración desde la rama 11.x puede planificarse en firme.
El equipo de lanzamientos de Kubernetes, sig-release, publicó el 26 de agosto de 2026 la versión 1.37.0, con el nombre en código "Garhwal" en referencia a la región montañosa del Himalaya en Uttarakhand, India, según la discusión oficial de aspectos destacados publicada en GitHub. Dieciséis funciones gradúan a estable en esta entrega, entre ellas la API metrics.k8s.io -que usan el autoescalado horizontal (HPA) y el comando kubectl top- tras casi nueve años en beta; la salida KYAML para kubectl, un dialecto de YAML con llaves para mapas y corchetes para listas pensado para evitar errores de interpretación; y la entrega de certificados X.509 a cargas de trabajo mediante volúmenes proyectados (Pod Certificates). Otras 23 funciones avanzan a beta, entre ellas el escalado a cero del HPA y el modo "rootless" del kubelet (Kubelet-in-UserNS), y 27 debutan en alpha, según el mismo registro. La entrega trae también cambios de ruptura que el sitio especializado en DevOps bex.co, en un análisis publicado el 24 de agosto, tituló "Kubernetes 1.37 Will Brick Your Fleet on Upgrade Day" (Kubernetes 1.37 va a inutilizar su flota el día de la actualización): describe que los pods estáticos ya no pueden referenciar Secrets ni ConfigMaps, que el modo ipvs de kube-proxy entra en una cuenta regresiva de tres versiones hacia su eliminación, y que el propio kubelet se niega a arrancar en nodos con cgroup v1 sin una bandera de excepción que el proyecto describe como solución temporal. La discusión oficial de sig-release matiza ese último punto: según ese mismo registro, cgroup v1 sigue deshabilitado por defecto sin cambios adicionales en esta versión, con su eliminación completa prevista para una entrega futura y no para la 1.37 -una diferencia de lectura entre el análisis externo y el propio equipo de lanzamientos sobre qué tan inmediato es el riesgo para clusters que todavía no migraron a cgroup v2. Costa Rica no publica cifras propias de adopción de Kubernetes, pero el orquestador es la base de facto de la infraestructura en la nube de bancos, telecomunicaciones y zonas francas tecnológicas del país, para quienes la discrepancia entre bex.co y sig-release sobre cgroup v1 es motivo suficiente para auditar primero, en un entorno de prueba, si sus nodos corren containerd 1.x -que requiere actualizarse a la versión 2.0 o superior antes de esta versión, según el mismo análisis- y si sus manifiestos de pods estáticos referencian Secrets o ConfigMaps, antes de programar la actualización en producción.
La versión 1.16.0, publicada el 26 de agosto, permite que los proveedores conserven datos privados entre plan y apply y suma un bloque terraform_data para valores efímeros y sensibles.
HashiCorp publicó, el 26 de agosto de 2026 a las 13:05 UTC, la versión 1.16.0 de Terraform, según el registro oficial de lanzamientos del proyecto en GitHub. La función central de esta entrega permite que los proveedores almacenen datos privados planificados entre las fases de plan y apply, de forma que un estado específico del proveedor se conserve entre ambos pasos; el nuevo bloque terraform_data sirve para retener valores efímeros y sensibles durante la planificación sin exponerlos en el estado. La versión también permite que los bloques import operen dentro de módulos -antes solo funcionaban en el módulo raíz-, agrega binarios para arquitectura Linux s390x (zLinux), y suma la bandera -format=mermaid al comando terraform graph para exportar diagramas de dependencias en ese formato, según el mismo registro de cambios. Entre las correcciones, la función merge() ya no falla con un error de pánico cuando recibe objetos nulos, y los valores efímeros opcionales dejaron de exigir una asignación obligatoria en tiempo de planificación. El registro de cambios advierte de un cambio de comportamiento que exige revisión antes de actualizar: el atributo bastion_host_key ahora se aplica correctamente a través de aprovisionadores (provisioners), lo que puede alterar configuraciones existentes que dependían del comportamiento anterior. HashiCorp mantiene Terraform bajo la licencia BSL adoptada en 2023 -la misma decisión que impulsó el nacimiento del proyecto derivado OpenTofu, con el que Terraform compite desde entonces por la base de usuarios de infraestructura como código. La información de esta nota proviene únicamente del registro oficial de lanzamientos de Terraform en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Terraform, pero la herramienta es una de las más usadas por equipos de plataforma locales -bancos, telecomunicaciones y empresas de zonas francas tecnológicas- para desplegar infraestructura en AWS y otros proveedores de nube, para quienes conviene revisar cualquier configuración que use provisionadores con bastion_host_key antes de actualizar a la 1.16.
cat /feed/devopscloudflareworkers.md
La versión 1.20260827.1, publicada el 27 de agosto, agrega un motor alternativo basado en zlib-rs para node:zlib y extiende a dieciséis la racha diaria del motor de Cloudflare Workers, personaje de la semana en esta sección.
> > workerd --version
> Cloudflare publicó, el 27 de agosto de 2026 a las 02:07 UTC, la versión 1.20260827.1 de workerd, el motor de ejecución de Cloudflare Workers, según el registro oficial de lanzamientos en GitHub. Es la decimosexta versión consecutiva que la compañía publica en otros tantos días, racha que arrancó el 12 de agosto. La entrega implementa zlib-rs como motor alternativo activable de forma gradual ("autogated") para node:zlib, corrige errores de desplazamiento (off-by-one) en las macros internas de TypedArray, retrasa la finalización de los rastros de telemetría (spans) hasta después de que la solicitud termina de procesarse, y actualiza Pyodide -el intérprete de Python que corre dentro de Workers- a la versión 314.0.6, según el mismo registro de cambios.
> > workerd diff v1.20260826.1..v1.20260827.1
> Dieciséis días sin una sola interrupción, del 12 al 27 de agosto, siguen siendo el hilo más sostenido de esta categoría en lo que va del mes, y esta sección mantiene a Cloudflare Workers como personaje de la semana. A diferencia de otras jornadas de la racha que solo cambiaron la marca de versión, la de hoy vuelve a traer cambios de código de fondo: un motor alternativo de compresión escrito en Rust es, junto con la migración de mise a usage-rs que esta sección documentó esta semana, el segundo caso reciente de una herramienta de desarrollo moviendo código crítico de rendimiento hacia ese lenguaje.
> > echo $COSTA_RICA
> La información de esta nota proviene únicamente del registro de lanzamientos oficial de Cloudflare Workerd en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de tráfico servido por Cloudflare Workers, pero equipos locales de zonas francas tecnológicas que corren cargas de Python sobre Workers mediante Pyodide pueden revisar la actualización a la versión 314.0.6 antes de su próxima puesta en producción, según el mismo registro de cambios.
GitHub publicó, el 26 de agosto de 2026 a las 18:21 UTC, la versión 1.0.81-12 de Copilot CLI, según el registro oficial de lanzamientos del proyecto en GitHub. La actualización suma soporte para el corredor de autenticación de Windows (WAM, Web Account Manager) en servidores MCP remotos protegidos por Microsoft Entra ID, lo que puede eliminar las ventanas de autenticación repetidas para cuentas empresariales, y corrige un bloqueo (crash) que ocurría al reanudar sesiones de forma repetida con reemplazo de telemetría activo. Menos de seis horas después, la versión 1.0.81-13, publicada el 27 de agosto a las 00:11 UTC, agrega contexto de trazas de OpenTelemetry a los "hooks" -scripts que se ejecutan en puntos definidos del ciclo de vida de una sesión- para correlacionar sus emisiones, registra los eventos de ciclo de vida de hooks disparados por subagentes, y elimina el selector heredado de "skills": los comandos /skills y /mcp abren directamente el panel correspondiente en lugar de un menú intermedio, según el mismo registro de cambios. La versión 1.0.81-14, publicada el 27 de agosto a las 03:39 UTC, mejora el tiempo de reanudación de sesiones largas mostrando primero el historial reciente mientras los mensajes antiguos siguen cargando en segundo plano, y corrige un error en la función read_agent que ahora devuelve el historial completo del turno salvo que se especifique el parámetro since_turn. Es ya la decimocuarta entrega de la serie 1.0.81 desde la v1.0.81-1 del 18 de agosto -tres versiones más desde que esta sección documentó la undécima el 26 de agosto-, un ritmo que la CLI de Copilot sostiene sin interrupciones desde hace más de una semana y que la mantiene, junto con Cloudflare workerd, entre los proyectos con el ritmo de publicación más agresivo que sigue esta sección. La información de esta nota proviene únicamente del registro oficial de lanzamientos de GitHub Copilot CLI en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de GitHub Copilot CLI, pero la herramienta gana terreno entre equipos de desarrollo locales que automatizan tareas de programación asistida, para quienes el soporte WAM de hoy interesa en particular a organizaciones que ya usan Microsoft Entra ID para controlar el acceso a sus servidores MCP internos.
El equipo de Next.js fusionó, el 26 de agosto de 2026, la solicitud de cambios (pull request) #97931, que reactiva la optimización de imágenes en formato AVIF y sube la dependencia sharp de la versión ^0.35.3 a la ^0.35.4, según el propio registro del cambio en GitHub. Esa versión de sharp incorpora sharp-libvips 1.3.3, que actualiza la biblioteca libheif de la 1.23.1 a la 1.23.2 y corrige, según la descripción del cambio, las fallas de seguridad de memoria en el decodificador de AVIF identificadas como GHSA-g89c-p67h-r497 y GHSA-2jg2-4ch7-h545 -la primera es la misma vulnerabilidad con puntuación CVSS de 9,5 sobre 10 que esta sección cubrió el 26 de agosto, cuando Next.js desactivó por completo la optimización de AVIF ante la falta de una solución alternativa. El cambio llegó a la rama canary con la versión 16.4.0-canary.9, publicada el 27 de agosto a las 00:43 UTC. Que la reactivación llegue primero a canary, y no directamente a la rama estable 16.3.3 que recibió el parche de emergencia el 25 de agosto, confirma el patrón que domina el ciclo de vida de esta falla: Next.js prioriza reducir la superficie de ataque de inmediato en producción -apagando la función entera- y solo restaura la funcionalidad una vez que la cadena de dependencias completa, de sharp a libvips y libheif, confirma la corrección aguas abajo. Las aplicaciones que corren hoy sobre las versiones estables 16.3.3 o 15.5.24 siguen sin optimización de AVIF hasta que ese cambio se traslade a una versión estable, algo que el registro consultado para esta nota todavía no fecha. Costa Rica no publica cifras propias de aplicaciones Next.js en producción, pero el framework es una de las bases más comunes entre agencias y startups locales que construyen sitios con React -esta sección documentó el 26 de agosto la corrección de las dos fallas críticas de ejecución remota que motivaron este apagado-, por lo que equipos que sirven imágenes AVIF sin proxy externo deberían tratar la reactivación de hoy como una señal de que la corrección de fondo avanza, no como una razón para reactivarla manualmente en producción antes de que llegue a una versión estable.
— Un cambio fusionado el 26 de agosto revierte la desactivación total de AVIF que Next.js aplicó como mitigación de emergencia, después de que sharp 0.35.4 actualizara libheif a la versión 1.23.2.
Entre la versión 12.0.0 estable de pnpm y el estreno de Kubernetes 1.37 "Garhwal", esta edición documenta seis desarrollos recientes del ecosistema de programación.
Esta edición documentó seis desarrollos del 26 y el 27 de agosto de 2026: la versión 12.0.0 de pnpm, que llega a estable tras once candidatas desde el 7 de agosto; la versión 1.37.0 de Kubernetes, con nombre en código "Garhwal", que gradúa dieciséis funciones a estable en medio de un desacuerdo entre un análisis independiente y el propio equipo de lanzamientos sobre el riesgo real de sus cambios de ruptura; la versión 1.16.0 de Terraform, con datos persistentes de proveedores y bloques de importación dentro de módulos; la versión 1.20260827.1 de Cloudflare workerd, decimosexta entrega consecutiva de una racha que arrancó el 12 de agosto; las versiones 1.0.81-12 a 1.0.81-14 de GitHub Copilot CLI, con soporte de autenticación de Windows para servidores MCP; y la reactivación de la optimización de imágenes AVIF en la rama canary de Next.js, tras el parche de libheif en sharp 0.35.4. El hilo que domina la jornada es la madurez desigual entre proyectos que compiten por el mismo terreno: pnpm cierra su ciclo de versión mayor en apenas diecinueve días desde la primera candidata, mientras Prisma sigue sin fecha de estable para su propia versión 8 y esta semana no sumó novedades para esta sección; Kubernetes gradúa dieciséis funciones el mismo día en que un análisis externo advierte sobre tres cambios de ruptura que podrían dejar clusters descuidados fuera de servicio. Cloudflare Workers y su motor workerd cierran el jueves como personaje de la semana en esta sección: dieciséis días consecutivos de lanzamientos, del 12 al 27 de agosto, con cambios de código reales en la entrega de hoy. Para equipos de desarrollo en Costa Rica, la lista de hoy exige dos verificaciones puntuales antes de cualquier actualización en producción: si los clusters de Kubernetes corren containerd 1.x o nodos con cgroup v1, revisarlos antes de saltar a la 1.37, y si las configuraciones de Terraform usan aprovisionadores con bastion_host_key, auditarlas antes de subir a la 1.16. El resto de la lista -pnpm 12, workerd, GitHub Copilot CLI y la reactivación de AVIF en Next.js- queda en fase de observación de rutina.