Kubernetes publicó la versión 1.36.4 y la primera candidata de la serie 1.37, Terraform corrigió una falla de exclusión de archivos mientras adelantaba funciones de la 1.16, Vite y Visual Studio Code sumaron correcciones de estabilidad, y Cloudflare workerd extendió a diez su racha diaria de versiones, personaje de la semana en esta sección.
La versión, publicada el 20 de agosto junto con la primera candidata de la serie 1.37, cierra una condición de carrera en el planificador y dos errores en la asignación dinámica de recursos.
El proyecto Kubernetes publicó, el 20 de agosto de 2026 a las 11:48 UTC, la versión 1.36.4, según el registro oficial de cambios del proyecto en GitHub. La actualización corrige cinco fallas: un problema de compatibilidad en client-go que impedía a FakeCustomStore implementar los métodos Bookmark y LastStoreSyncResourceVersion agregados en la versión 0.36; un error de asignación dinámica de recursos (DRA) por el que dos controladores que publicaban un grupo con el mismo nombre en un nodo podían usar las definiciones de contador uno del otro; una condición de carrera en el planificador que dejaba a un pod expulsado por preemption atascado en estado no programable; y un defecto en el kubelet por el que reintentar una preparación de recursos fallida a medias generaba identificadores de dispositivo CDI duplicados. La misma versión actualiza las dependencias golang.org/x/text y golang.org/x/net por motivos de seguridad. Horas antes, a las 02:44 UTC del mismo día, el proyecto también publicó v1.37.0-rc.1, la primera candidata de la siguiente serie mayor, sin que el registro de cambios consultado para esta nota detalle todavía las funciones nuevas de esa rama. De las cinco correcciones de la 1.36.4, dos apuntan al mismo subsistema: la asignación dinámica de recursos, la función que permite a Kubernetes repartir hardware especializado como GPU entre cargas de trabajo. Que un solo parche de mantenimiento necesite dos arreglos distintos en DRA —uno en el planificador, otro en el kubelet— matiza la imagen de una función ya asentada: el propio historial de versiones recientes de Kubernetes muestra que DRA sigue generando fallas de coordinación entre componentes, no errores aislados y ya cerrados. Kubernetes sigue siendo la capa de orquestación de facto para cargas de trabajo en contenedores en la nube, por lo que un error de planificación que deja pods atascados afecta directamente la capacidad de escalar servicios en producción. La información de esta nota proviene únicamente del registro oficial de lanzamientos de Kubernetes en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de clústeres de Kubernetes en producción, pero la plataforma es la base de facto de los equipos de infraestructura en zonas francas tecnológicas y bancos locales que operan en la nube; a esos equipos les conviene aplicar la 1.36.4 si usan asignación dinámica de recursos, y dejar la candidata 1.37.0-rc.1 fuera de producción hasta que exista una versión estable.
cat /feed/devopscloudflareworkers.md
La versión 1.20260820.1, publicada el 20 de agosto, amplía a 4 MiB el límite de fila de SQLite y agrega pistas de ubicación para instancias de flujos de trabajo, la décima entrega consecutiva del motor de Cloudflare Workers.
> > workerd --version
> Cloudflare publicó, el 20 de agosto de 2026 a las 00:49 UTC, la versión 1.20260820.1 de workerd, el motor de ejecución de Cloudflare Workers, según el registro oficial de lanzamientos en GitHub. Es la décima versión que la compañía publica en otros tantos días consecutivos desde el 12 de agosto, racha que esta sección adoptó como personaje de la semana. Los cambios de hoy: amplía a 4 MiB el límite de tamaño de fila en el motor SQLite embebido que usan Durable Objects; corrige el mensaje de error que aparecía cuando un paquete de workers-py no cumplía el requisito de versión declarado; agrega pistas de ubicación (location hints) a las instancias de Workflows; suma capacidades de rasterización de texto al binding de Images; y mejora los tipos del árbol de accesibilidad expuestos al navegador, según el mismo registro de cambios.
> > workerd diff v1.20260819.1..v1.20260820.1
> La versión de ayer, 19 de agosto, se concentró en retirar anotaciones experimentales del registro de módulos y en volver estático el método importKeySync; la de hoy no toca ese terreno y en cambio amplía límites de almacenamiento y pule mensajes de error, sin corregir fallas de seguridad ni de memoria como sí ocurrió en versiones anteriores de la semana. Diez lanzamientos seguidos sin interrupción confirman que la cadencia de workerd —generada por el propio flujo de integración continua de Cloudflare— se sostiene incluso cuando el contenido de cada entrega varía entre correcciones internas y ampliaciones de límites técnicos.
> > 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 de zonas francas tecnológicas que despliegan funciones de borde sobre la plataforma pueden aprovechar el nuevo límite de 4 MiB por fila si almacenan más datos dentro de un mismo Durable Object.
HashiCorp publicó, el 19 de agosto de 2026 a las 14:29 UTC, la versión 1.15.9 de Terraform, según el registro oficial de lanzamientos del proyecto en GitHub. La actualización corrige la validación de módulos hijos para que levante correctamente diagnósticos de error y advertencia en bloques inválidos —list, import, backend y cloud— y repara CVE-2026-14978, una falla de normalización Unicode en la dependencia go-slug, ya actualizada a la versión 0.18.3, que podía hacer que archivos con ciertos nombres no quedaran correctamente excluidos por un .terraformignore durante subidas a Terraform Enterprise o HCP Terraform, según la misma fuente. Dos horas antes, a las 12:08 UTC del mismo día, HashiCorp publicó también 1.16.0-rc2, segunda candidata de la próxima serie mayor, con persistencia de datos privados por proveedor entre plan y apply, un bloque store nuevo para valores efímeros y sensibles en terraform_data, soporte de bloques import dentro de módulos, binarios precompilados para Linux s390x, modos on_failure (halt, taint, continue) en los disparadores de acción de recursos, y salida en formato Mermaid para terraform graph. HashiCorp no publicó, en las notas de la 1.15.9, una puntuación CVSS para CVE-2026-14978, lo que dificulta a los equipos priorizar el parche solo con esa información; la propia descripción del defecto —un archivo que debía excluirse termina subiéndose de todas formas— apunta a un riesgo de exposición de datos sensibles en configuraciones de infraestructura como código, no a ejecución remota de código. El hecho de que HashiCorp publique el mismo día un parche de seguridad para la rama estable y una candidata con funciones nuevas para la próxima serie mayor refleja el costo de mantener dos ramas de desarrollo en paralelo: cada corrección de seguridad tiene que aplicarse por separado en la rama en desarrollo. 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 o HCP Terraform, pero la herramienta es estándar entre equipos de infraestructura como código de bancos y empresas de zonas francas tecnológicas que administran su nube desde el país, a los que conviene revisar si su configuración de .terraformignore excluye archivos con nombres que usan normalización Unicode antes de actualizar a la 1.15.9.
El equipo de Vite publicó, el 20 de agosto de 2026 a las 04:08 UTC, la versión 8.2.2 de la herramienta de compilación para proyectos web, según el registro oficial de cambios del proyecto en GitHub. El cambio central corrige el reemplazo de módulos en caliente (HMR) para que siga funcionando cuando existen importaciones circulares entre archivos, en vez de forzar una recarga completa del navegador como ocurría hasta ahora. La misma versión corrige el manejo de errores en solicitudes diferidas (lazy) durante el modo de desarrollo empaquetado; ajusta la resolución de rutas de mapas de fuente (sourcemaps); evita que el procesamiento de CSS le pase objetivos vacíos a lightningcss; corrige que las claves de definición con prefijo de signo de dólar no coincidieran correctamente; hace que la detección de ciclos en el ejecutor de módulos excluya los módulos ya completados; cierra correctamente los paquetes de análisis de extensiones personalizadas; reduce falsos positivos en la detección de nombres cortos de Windows; respeta la opción resolve.preserveSymlinks al resolver la raíz del proyecto; y corrige la reescritura de parámetros de desestructuración calculados en renderizado del lado del servidor (SSR), según el mismo registro de cambios. La versión también amplía el rango de la dependencia de pares @vitejs/devtools hasta la v0.5.0. La corrección de HMR en importaciones circulares resuelve un problema común en proyectos grandes: dos módulos que se referencian mutuamente son habituales en aplicaciones con estado compartido o utilidades cruzadas, y hasta ahora un cambio en cualquiera de los dos forzaba perder el estado de la aplicación con una recarga completa del navegador, uno de los principales beneficios que promete el desarrollo con recarga en caliente. La versión llega una semana después de la 8.2.1 del 6 de agosto y dos semanas después de la 8.2.0 del 30 de julio, que introdujo la opción input y un modo de desarrollo empaquetado con soporte de HMR; la 8.2.2 no suma funciones nuevas, sino que corrige comportamientos de esas dos versiones anteriores. La información de esta nota proviene únicamente del registro oficial de lanzamientos de Vite en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Vite, pero la herramienta es una opción común entre agencias y startups locales que construyen aplicaciones con React, Vue o Svelte, a las que conviene actualizar sin mayor riesgo, dado que la 8.2.2 es un lanzamiento de corrección de errores, no de funciones nuevas.
Microsoft publicó, el 19 de agosto de 2026, la versión 1.134 de Visual Studio Code, según el registro oficial de lanzamientos del proyecto en GitHub y las notas de la versión publicadas por el equipo del editor. Entre los cambios que no tienen que ver con las funciones de chat con agentes de inteligencia artificial —que corresponden a la categoría de IA de esta edición—, la versión permite configurar el navegador integrado como editor por defecto para archivos HTML, combinando la vista previa con la asociación de archivos en un solo flujo; agrega un atajo para mantener presionada la tecla Alt mientras se hace clic en el botón de cerrar de una pestaña, lo que activa "cerrar los demás editores" sin pasar por el menú contextual; mejora el diseño de panel único lateral para que respete la configuración de visibilidad de pestañas, muestre las migas de pan de archivo de forma consistente y mantenga estable el diseño al cambiar de sesión; y corrige varias fugas de memoria detectadas en extensiones, en la vista de búsqueda y en el control de código fuente, según las notas de la versión. Las fugas de memoria en un editor que millones de programadores mantienen abierto durante jornadas completas de trabajo se traducen, con el tiempo, en máquinas que se vuelven más lentas sin que el usuario sepa por qué; corregirlas en extensiones, búsqueda y control de código fuente —tres de las funciones que un programador usa constantemente durante el día— tiene un efecto directo en la experiencia diaria, aunque no venga acompañado de una función vistosa nueva. El resto de la versión 1.134 se concentra, según las mismas notas, en ampliar las funciones de sesiones de agentes de IA con capacidades como grupos de conversación en cuadrícula y una línea de tiempo de solicitudes, cambios que esta sección deja fuera de su cobertura por corresponder a la categoría de inteligencia artificial de El Pisuika. La información de esta nota proviene únicamente del registro oficial de lanzamientos de Visual Studio Code en GitHub y de las notas de versión del propio proyecto, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de uso de Visual Studio Code, pero el editor domina las máquinas de programadores en bootcamps, universidades y empresas de zonas francas tecnológicas del país, para quienes esta actualización no exige ningún cambio de flujo de trabajo: las correcciones de memoria y las funciones de edición llegan sin romper compatibilidad con extensiones existentes.
— La versión, publicada el 19 de agosto, permite fijar el navegador integrado como editor por defecto para archivos HTML y cierra fugas de memoria en extensiones, búsqueda y control de código fuente.
Entre un parche de Kubernetes con dos correcciones en asignación de recursos y un CVE de Terraform sin puntuación de severidad publicada, esta edición documenta cinco desarrollos recientes en el ecosistema de programación.
Esta edición documentó cinco desarrollos del 19 y el 20 de agosto de 2026: la versión 1.36.4 de Kubernetes, que corrige cinco fallas —dos de ellas en asignación dinámica de recursos— junto con la primera candidata de la serie 1.37; la versión 1.15.9 de Terraform, que repara CVE-2026-14978 mientras la candidata 1.16.0-rc2 adelanta funciones de la próxima serie mayor; la décima versión consecutiva de Cloudflare workerd, hoy centrada en ampliar límites de almacenamiento; la versión 8.2.2 de Vite, que corrige el recargado en caliente en importaciones circulares; y la versión 1.134 de Visual Studio Code, con una vista HTML integrada y correcciones de fugas de memoria. El hilo que domina la jornada es la brecha entre lo que un parche de mantenimiento promete y lo que en realidad expone: dos de las cinco correcciones de Kubernetes 1.36.4 tocan la asignación dinámica de recursos, una función que el proyecto sigue afinando a nivel de planificador y kubelet, mientras HashiCorp corrigió una falla de seguridad en Terraform sin publicar una puntuación CVSS que ayude a priorizar el parche. Cloudflare Workers y su motor workerd continúan como personaje de la semana en esta sección: diez versiones consecutivas desde el 12 de agosto, hoy con un límite de fila de SQLite ampliado a 4 MiB, confirman que la cadencia diaria se sostiene incluso en una semana sin fallas de seguridad que corregir. Para equipos de desarrollo en Costa Rica, la lista de hoy suma tareas concretas: aplicar 1.36.4 en cualquier clúster de Kubernetes que use asignación dinámica de recursos y mantener 1.37.0-rc.1 fuera de producción; revisar la configuración de .terraformignore antes de actualizar Terraform a la 1.15.9; y actualizar sin mayor riesgo tanto Vite 8.2.2 como Visual Studio Code 1.134, dos lanzamientos de corrección que no rompen compatibilidad con proyectos existentes.