Política de lanzamiento de Godot

La politica de lanzamiento de Godot está en constante evolución. La descripción siguiente da una idea general de qué es lo que se espera, pero lo que actualmente suceda dependerá de las decisiones de contribuyentes principales y de las necesidades de la comunidad en un determinado momento.

Versionado de Godot

Godot sigue vagamente Semantic Versioning <https://semver.org/> __ con un sistema de versionado `` major.minor.patch`` , aunque con una interpretación de cada término adaptada a la complejidad de un motor de juego:

La versión major es incrementada cuando ocurren rupturas de compatibilidad lo que implica un trabajo significante de porteo para mover proyectos de una mayor versión a otra.

Por ejemplo, la migración de proyectos de Godot 3.x a Godot 4.x requiere pasar el proyecto a través de una herramienta de conversión, y luego realizar una serie de ajustes manualmente en lo que la herramienta no pudo hacer automaticamente.
La versión menor se incrementa para las versiones de funcionalidad que no rompen la compatibilidad de manera importante. Pueden producirse fallas menores en la compatibilidad en áreas muy específicas en versiones menores, pero la gran mayoría de los proyectos no deberían verse afectados o requerir un trabajo de migración significativo.

Esto es porque Godot, como motor de videojuegos, cubre muchas áreas tales como renderizado, física, scripting, etc. Arreglar bugs o implementar nuevas características a un área puede en algunas ocasiones requerir cambiar el comportamiento de alguna característica o modificar la interfaz de una clase determinada, incluso si el resto del API del motor se mantiene compatible con sus versiones anteriores.

Truco

Por lo tanto, se recomienda a todos los usuarios actualizar a una nueva versión menor, pero es necesario realizar algunas pruebas para asegurarse de que tu proyecto aún se comporta como se espera.

La versión parche se incrementa para las versiones de mantenimiento que se centran en la corrección de errores y problemas de seguridad, la implementación de nuevos requerimientos para el soporte de la plataforma, y el backport de mejoras de usabilidad seguras. Estas son compatibles con versiones anteriores.

Las versiones Parche deberán incluir nuevas características menores que no impactaran en la API existente, y por lo tanto no corren riesgo de impactar en los proyectos existentes.

Truco

La actualización a nuevas versiones de parche es por lo tanto considerada segura y fuertemente recomendada a todos los usuarios de una rama estable dada.

Las combinaciones mayor.menor se denominan ramas estables. Cada rama estable comienza con una versión mayor.menor (sin el 0 para parche) y se desarrolla para las versiones de mantenimiento en una rama Git del mismo nombre (por ejemplo, las actualizaciones de parches para la rama estable 4.0 se desarrollan en la rama Git 4.0).

Línea de tiempo del soporte de liberación

Las ramas estables son compatibles como mínimo hasta que se lance la siguiente rama estable y esta haya recibido su primera actualización de parche. En la práctica, soportamos las ramas estables en base al mejor esfuerzo mientras tengan usuarios activos que necesiten actualizaciones de mantenimiento.

Siempre que se lanza una nueva versión mayor, hacemos de la rama estable anterior una versión con soporte a largo plazo y hacemos todo lo posible para proporcionar soluciones a los problemas que encuentran en esa rama los usuarios que no pueden migrar proyectos complejos a la nueva versión mayor. Este es fue el caso de la rama 2.1, y es el caso de la rama 3.x.

En una serie de versiones inferiores determinada, solo se admite la última versión del parche. Si tienes algún problema al utilizar una versión de parche anterior, actualice a la versión de parche más reciente de esa serie y vuelva a realizar la prueba antes de informar un problema en GitHub.

Versión	Fecha de lanzamiento	Nivel de soporte
Godot 4.5 (master)	El tercer trimestre de 2025 (estimado)	\|inestable\| Desarrollo. Recibe nuevas características, mejoras de usabilidad y rendimiento, así como correcciones de errores, mientras está en desarrollo.
Godot 4.4	Marzo de 2025	Recibe correcciones de errores y problemas de seguridad, así como parches que habilitan el soporte de la plataforma.
Godot 4.3	Agosto 2024	Recibe correcciones de errores y problemas de seguridad, así como parches que habilitan el soporte de la plataforma.
Godot 4.2	Noviembre de 2023	Únicamente recibe arreglos de seguridad y parches que habilitan el soporte de plataformas.
Godot 4.1	Julio de 2023	Ya no recibe soporte (ultima actualización: 4.1.4).
Godot 4.0	Marzo de 2023	Ya no recibe soporte (ultima actualización: 4.0.4).
Godot 3.6 (3.x)	No hay un ETA por el momento	\|soportado\| Beta. Recibe nuevas características, mejoras de usabilidad y desempeño así como correcciones de errores mientras está en desarrollo.
Godot 3.6	Septiembre 2024	Recibe correcciones de errores y problemas de seguridad, así como parches que habilitan el soporte de la plataforma.
Godot 3.5	Agosto 2022	Únicamente recibe arreglos de seguridad y parches que habilitan el soporte de plataformas.
Godot 3.4	Noviembre de 2021	Ya no se admite (última actualización: 3.4.5).
Godot 3.3	Abril de 2021	Esta versión ya no recibe soporte (última actualización: 3.3.4).
Godot 3.2	Enero de 2020	Esta versión ya no es soportada (última actualización: 3.2.3).
Godot 3.1	Marzo de 2019	Esta versión ya no es soportada (última actualización: 3.1.2).
Godot 3.0	Enero de 2019	Esta versión ya no es sostenida (Ultima actualización: 3.0.6).
Godot 2.1	Julio de 2016	Esta versión ya no es soportada (última actualización: 2.1.6).
Godot 2.0	Febrero de 2016	Esta versión ya no es sostenida (ultima actualización: 2.0.4.1).
Godot 1.1	Mayo de 2015	Ya no es compatible.
Godot 1.0	Diciembre de 2014	Ya no es compatible.

Las versiones de Godot anteriores al lanzamiento no están pensadas para ser utilizadas en la producción y se proporcionan solo con el propósito de realizar pruebas.

Ver también

Ver Actualizar de Godot 3 a Godot 4 para instrucciones de migración de proyectos de Godot 3.x a 4.x.

¿Qué versión debería usar para un proyecto nuevo?

Recomendamos utilizar Godot 4.x para proyectos nuevos, ya que la serie Godot 4.x será soportada por mucho tiempo después de que 3.x deje de recibir actualizaciones en el futuro. Un detalle es que mucha de la documentación no ha sido actualizada a Godot 4.x todavía, si estás siguiendo un tutorial diseñado para Godot 3.x, recomendamos tener Actualizar de Godot 3 a Godot 4 abierta en una pestaña separada para revisar cuáles métodos fueron renombrados (si tienes un error de scripting mientras intentas utilizar un nodo o método específico que fue renombrado en Godot 4.x).

Si tu proyecto requiere una característica que no está disponible en 4.x (como GLES2/WebGL 1.0), deberías usar Godot 3.x para un proyecto nuevo.

¿Debería actualizar mi proyecto a una versión nueva del motor?

Nota

Actualizar software mientras se trabaja en un proyecto es inherentemente riesgoso, así que considera si será una buena idea para tu proyecto antes de intentar actualizar. También haz copias de seguridad de tu proyecto o utiliza un sistema de control de versiones para prevenir la pérdida de datos en caso de que una actualización salga mal.

Dicho esto, hacemos lo mejor posible para mantener las versiones menor y especialmente parche compatibles con proyectos existentes.

La recomendación general es actualizar tu proyecto siguiendo las versiones parche, como actualizar de 4.0.2 a 4.0.3. Esto asegura que tendrás bugs arreglados, soporte de actualizaciones de seguridad y actualizaciones de plataforma (lo que es importante especialmente en plataformas móviles). También tendrás soporte contínuo, ya que sólo las últimas versiones parche reciben soporte en plataformas oficiales de la comunidad.

Para versiones menores deberías determinar caso por caso si es una buena idea actualizar. Hemos hecho el mayor esfuerzo para lograr que el proceso de actualización sea lo más simple posible, pero algunos cambios incompatibles pueden estar presentes en versiones menores, jusnto con un mayor riesgo de regresiones. Algunos arreglos incluídos en versiones menores también pueden cambiar el comportamiento esperado de alguna clase ya que puede requerirse para resolver bugs. Esto es especialmente el caso de clases marcadas como experimental en la documentación.

Versiones mayores agregan muchas nuevas funcionalidades, pero también remueven funcionalidad existente y pueden incrementar los requerimientos de hardware. Estas también requieren más trabajo para actualizar en comparación con las versiones menores. Como resultado, recomendamos quedarse con la versión mayor con la que has iniciado el proyecto si estás satisfecho en como tu proyecto funciona actualmente. Por ejemplo, si tu proyecto comenzó con 3.5, recomendamos actualizar a 3.5.2 y posiblemente 3.6 en el futuro, pero no a 4.0+ a menos qu tu proyecto necesite las características nuevas que vienen con 4.0+.

¿Cuándo sale el próximo lanzamiento?

Mientras que los contribuyentes de Godot no trabajan bajo ninguna fecha limite, nos esforzamos por publicar lanzamientos menores con relativa frecuencia.

En particular, después del ciclo de lanzamiento muy largo para 4.0, estamos cambiando a un flujo de desarrollo de ritmo más rápido, 4.1 se lanzó 4 meses después de 4.0 y 4.2 se lanzó 4 meses después de 4.1.

Versiones menores frecuentes nos habilitan a lanzar nuevas características rápidamente (posiblemente como experimental), obtener retroalimantación de usuarios rápido e iterar para mejorar esas características y su usabilidad. Asimismo, la experiencia de usuario general mejorará sólidamente con un camino más rápido a los usuarios finales.

Las correcciones de errores o parches se publicarán cuando sea necesario con ciclos de desarrollo potencialmente muy cortos, para proveer a los usuarios de la rama estable actual de las ultimas correcciones de bugs para sus necesidades de producción.

Actualmente no hay fecha de lanzamiento para la próxima versión secundaria 3.x (la 3.7). La versión estable actual (3.6), quizá sea la última rama estable de Godot 3.x. Godot 3.x recibirá el mejor soporte que pueda, mientras los colaboradores sigan manteniéndolo.

¿Cuáles son los criterios de compatibilidad entre versiones del motor?

Nota

Esta sección está destinada para ser usada por contribuyentes para determinar qué cambios son seguros para cierta versión. La lista n es exhaustiva; sólo delinea las situaciones más comunes encontradas durante el desarrollo de Godot.

Los siguientes cambios son aceptables para una versión parche:

Arreglando un bug de manera que no tenga impacto negativo mayor en la mayoría de los proyectos, como un bug visual o de física. El motor de física de Godot no es determinista, por lo que bugs de física pueden no ser considerados como problemas de compatibilidad. Si arreglar un bug tiene un impacto negativo que pueda afectar muchos proyectos, debería ser hecho como opcional (por ej. utilizando ajustes de proyecto o un método aparte).
Agregar un nuevo parámetro opcional a un método.
Pequeños ajustes de usabilidad del editor.

Ten en cuenta que tendemos a ser conservativos con las correcciones que permitimos en versiones parche. Por ejemplo, 4.0.1 podrá recibir correcciones más importantes que 4.0.4.

Los siguientes cambios son aceptables en versiones menores, pero no en versiones parche:

Características nuevas destacadas.
Renombrando el parámetro de métodos. En C#, los parámetros pueden pasarse por nombre (no así en GDScript). Como resultado esto puede romper proyectos que usen C#.
Deprecando un método, una variable miembro, o una clase. Esto se realiza añadiendo una bandera de deprecado a su referencia de clase que aparecerá en el editor. Cuando un método es marcado como deprecado, está planeada su eliminación en la siguiente versión mayor.
Cambios que afectan el tema visual por defecto de los proyectos.
Arreglos de bugs que puedan cambiar el comportamiento o la salida significativamente, con el objetivo de satisfacer mejor las espectativas de los usuarios. En comparación, en versiones parche favorecemos mantener un comportamiento defectuoso así no rompemos proyectos existentes que puedan estar dependiendo de ese problema o usando una solución alternativa.
Optimizaciones de rendimiento que resulten en cambios visuales.

Los siguientes cambios son considerados de incompatibilidad y pueden ser realizados solamente en versiones mayores:

Renombrar o eliminar un método, una variable de miembro o una clase.
Modificar la el árbol de herencia de un nodo haciéndolo heredar de una clase diferente.
Cambiar el valor por defecto de un valor de ajustes de proyecto de un modo que afecte proyectos existentes. Para afectar nuevos proyectos, el administrador de proyectos debería escribir en un project.godot modificado.

Como todavía no se ha creado la rama Godot 5.0, actualmente no recomendamos hacer cambios de incompatibilidad de este tipo.

Nota

Al modificar la firma de un método (incluida la adición de un parámetro opcional), se debe crear un método de compatibilidad con GDExtension. Esto garantiza que las GDExtensiones existentes sigan funcionando en las actualizaciones y versiones menores, evitando así que los usuarios tengan que recompilarlas. Consulta Manejo de ruptura de compatibilidad para obtener más información.