Up to date

This page is up to date for Godot 4.2. If you still find outdated information, please open an issue.

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 última rama 3.6.

En una serie de versiones inferiores determinada, solo se admite la última versión del parche. Si tiene 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 publicación*

Nivel de soporte

Godot 4.3 (master)

April 2024 (estimate)

|inestable| En desarrollo. Recibe nuevas características, mejoras de usabilidad y desempeño así como correcciones de errores mientras está en desarrollo.

Godot 4.2

November 2023

|soportada| Recibe correcciones para errores, problemas de seguridad y así como parches que habiliten el soporte de plataformas.

Godot 4.1

Julio de 2023

|soportada| Recibe correcciones para errores, problemas de seguridad y así como parches que habiliten el soporte de plataformas.

Godot 4.0

Marzo de 2023

eol No longer supported (last update: 4.0.4).

Godot 3.6 (3.x, LTS)

Q1 2024 (estimate)

|soportado| Beta. Recibe nuevas características, mejoras de usabilidad y desempeño así como correcciones de errores mientras está en desarrollo.

Godot 3.5

Agosto 2022

|soportada| Recibe correcciones para errores, problemas de seguridad y así como parches que habiliten el soporte de plataformas.

Godot 3.4

Noviembre de 2021

eol No longer supported (last update: 3.4.5).

Godot 3.3

Abril de 2021

eol No longer supported (last update: 3.3.4).

Godot 3.2

Enero de 2020

eol Esta versión ya no es soportada (última actualización: 3.2.3).

Godot 3.1

Marzo de 2019

eol Esta versión ya no es soportada (última actualización: 3.1.2).

Godot 3.0

Enero de 2019

eol Esta versión ya no es sostenida (Ultima actualización: 3.0.6).

Godot 2.1

Julio de 2016

eol Esta versión ya no es soportada (última actualización: 2.1.6).

Godot 2.0

Febrero de 2016

eol Esta versión ya no es sostenida (ultima actualización: 2.0.4.1).

Godot 1.1

Mayo de 2015

eol Sin soporte.

Godot 1.0

Diciembre de 2014

eol Sin soporte.

Leyenda: |soportado| Soporte completo - |parcial| Soporte parcial - eol No hay soporte (fin de vida) - |inestable| Versión de desarrollo

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 Upgrading from Godot 3 to 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 Upgrading from Godot 3 to 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 backups para 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 largo ciclo de lanzamiento para 4.0, estamos cambiando a un flujo de desarrollo más rápido, con 4.1 esperado al final de Q2/inicios de Q3 2023.

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.

La versión 3.6 todavía está planeada y será la última versión estable de Godot 3.x. Esta será una versión de Soporte de Largo Plazo (LTS), la cual planeamos soportar mientras los usuarios la necesiten (ya sea por características no disponibles en Godot 4.x o por tener juegos publicados que necesiten ser actualizados por requerimientos de plataforma).

¿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

Cuando se modifica la firma de un método de cualquier modo (incluyendo parámetros opcionales), debe crearse un método de compatibilidad GDExtension. Esto asegura que las GDExtensions existentes continuen funcionando entre versiones parche y menores, así los usuarios no deben recompilarlas. Ver pull request #76446 para más información.