Acuerdo de soporte de versiones

Acuerdo de soporte de versiones

Este documento describe la política de versionado aplicada tanto al Scene Editor en Creator Hub como al framework de scripting (el @dcl/sdk paquete).

El objetivo de esta política de versionado es forjar un contrato entre el equipo del SDK de la Decentraland Foundation y los creadores de contenido, establecer expectativas claras y permitir que los creadores de contenido planifiquen su trabajo en consecuencia.

Definiciones

• Número de versión -- un identificador único para una versión de software disponible públicamente. Este identificador consta de una versión mayor y una versión menor separadas por puntos (por ejemplo, 7.2).

• Familia de versiones -- todas las versiones que tienen la misma versión mayor forman una familia. Llamamos sucesora a la versión A de la versión B si A y B pertenecen a la misma familia y el número menor de A es mayor que el de B (por ejemplo, 7.11 es sucesora de 7.10). sucesora

• Cambio que rompe compatibilidad -- un cambio que obliga a un usuario a modificar su código o activos para mantenerlos en estado funcional. Por ejemplo, una propiedad cambia de nombre y obliga al usuario a cambiar ese nombre de propiedad cada vez que se usa en su código.

• Cambio no rompedor -- un cambio que no requiere ninguna acción por parte del usuario. El comportamiento y las propiedades del código y los activos del usuario permanecen sin cambios.

• Versión estable -- una versión que prohíbe cambios que rompan compatibilidad en todas sus sucesoras (que también se consideran estables). Cualquier cambio que rompa compatibilidad debe introducirse únicamente mediante la creación de una nueva familia de versiones aumentando el número de versión mayor; sin embargo, vea la advertencia en la cambios que rompen compatibilidad sección. Los cambios no rompientes se reflejan incrementando el número de versión menor.

• Versión inestable -- una versión que permite cambios que rompan compatibilidad en sus sucesoras. Los cambios que rompen compatibilidad pueden introducirse incrementando el número de versión menor.

Política de soporte

En cada familia de versiones estable, la Decentraland Foundation solo admite la última versión menor. En cualquier momento debería haber como máximo dos familias admitidas.

Por ejemplo, si la última versión menor de la familia 6.x es 6.11, y la última versión menor de la familia 7.x es 7.3, se espera que los creadores de contenido desarrollen sus escenas en 6.11 o 7.3. Las escenas que fueron desarrolladas y publicadas con la versión 6.10 o anterior muy probablemente seguirán funcionando y los jugadores podrán disfrutarlas. Sin embargo, si estas escenas antiguas experimentan algún problema, primero deben actualizarse a una versión soportada, y el problema solo se investigará si aún ocurre en una versión soportada.

El Scene Editor actualiza automáticamente el paquete de scripting de todas las escenas dentro de la misma familia de versiones, de modo que todos los desarrolladores usen la última versión soportada al desarrollar sus escenas.

Desarrollo de funciones

Las nuevas funciones solo se lanzarán en la última versión en desarrollo. Tan pronto como el equipo de desarrollo comience a trabajar en una nueva familia de versiones, las familias de versiones más antiguas que permanezcan en soporte solo recibirán correcciones importantes de errores, y no se implementarán características adicionales.

Cambios que rompen compatibilidad

Los cambios que rompen compatibilidad deben ocurrir solo en lanzamientos mayores. No debe haber cambios que rompan compatibilidad dentro de los lanzamientos menores estables de la misma familia de versiones, salvo en caso de emergencia cuando no haya otros medios para abordarlo. Los cambios que rompen compatibilidad dentro de un lanzamiento menor son una medida drástica que los desarrolladores evitarán a toda costa. Los nuevos lanzamientos menores ampliarán las capacidades de la sintaxis existente, pero nunca deberían cambiar lo que produce la sintaxis establecida, excepto al corregir errores.

Cambios aislados

En ocasiones muy raras, puede ser preferible realizar un pequeño cambio aislado que rompa compatibilidad si solo perjudica a un pequeño subconjunto de usuarios. (Crear una nueva versión mayor perjudica a todos los usuarios). En este caso, el SDK podría desaprobar una característica, pero debe seguir soportándola durante un período de tiempo razonable.

Cambios de emergencia

En ciertos casos excepcionales, como preocupaciones de seguridad o requisitos regulatorios, cualquier característica puede cambiarse de manera que rompa compatibilidad independientemente de su nivel de estabilidad, y en estas situaciones no se promete una desprecación.

Lanzamientos estables e inestables

Alfa

Siempre que se introduce un nuevo lanzamiento mayor, algunas versiones menores iniciales pueden etiquetarse como inestables alpha versiones. En las versiones alfa deben permitirse y esperarse cambios que rompan compatibilidad, y los usuarios no deben esperar estabilidad.

Los desarrolladores son libres de experimentar con estas versiones alfa, pero no se les anima a publicar contenido creado con versiones alfa inestables, ya que no hay garantía de que el contenido siga funcionando después de cambios posteriores. Tampoco se recomienda comenzar migraciones grandes y complicadas en este punto, ya que pueden ser necesarios más cambios antes del siguiente lanzamiento estable.

Beta

Una vez que una familia de versiones alcanza cierto nivel de madurez, se pone a disposición un lanzamiento beta Un lanzamiento beta se considera completo y listo para ser declarado estable, sujeto a pruebas públicas.

Las familias de versiones beta deben ser lo más estables posible; sin embargo, se les permite cambiar con el tiempo. Estos cambios deben ser mínimos pero pueden incluir cambios que rompan compatibilidad. Los cambios que rompen compatibilidad solo pueden introducirse tras un período razonable de desaprobación para dar a los creadores de contenido la oportunidad de migrar sus escenas. Este período de desaprobación debe definirse cuando se introduce el cambio que rompe compatibilidad.

Las familias de versiones beta solo deben estar en beta por un período limitado de tiempo, especificado en el momento de ser marcadas como beta. Deben promocionarse a estables si no se encuentran problemas durante ese período. La duración de este período puede variar según el caso, pero una buena regla general es 90 días.

El contenido escrito con la sintaxis de una versión beta debe ser fácil de migrar a versiones posteriores dentro de esa familia. Aún no es recomendable desarrollar contenido para eventos importantes con una versión beta, ya que las pruebas aún están en progreso y es probable que haya errores.

Estable

Una vez que el período de tiempo beta finaliza sin problemas importantes, la familia de versiones se considera estable y no debería haber más cambios en la sintaxis, aparte de la adición de nuevas características. A partir de este punto, la versión se considera la opción recomendada y fomentada para que todos los desarrolladores la utilicen.

Una familia de versiones estable debe recibir soporte completo durante su vida útil. No debe haber cambios que rompan compatibilidad, sujeto a las advertencias descritas a continuación.

Características inestables en lanzamientos estables

Características específicas en un lanzamiento pueden tener niveles de estabilidad diferentes al del lanzamiento en su conjunto. Esto puede deberse a que la característica se ha introducido recientemente y requiere más pruebas, o porque está destinada a ser reemplazada pronto.

Por ejemplo, un nuevo tipo de componente podría introducirse como alfa en un lanzamiento ya estable del framework del SDK, ya que este componente en particular puede necesitar todavía su propio ciclo de pruebas. Luego puede someterse al flujo de versionado descrito anteriormente, pasando de alfa a beta y a estable.

Cualquier característica de un lanzamiento estable que no se considere estable debe etiquetarse claramente como tal en la documentación. Los creadores que utilicen características inestables deben ser conscientes de que la característica podría sufrir cambios que rompan compatibilidad. Cualquier cambio que rompa compatibilidad será comunicado claramente, incluyendo guías de migración, y habrá un período de transición para que los creadores ajusten el código de su escena.

¿Cuánto tiempo soportamos una familia de versiones estable?

Una vez que una nueva familia de versiones se vuelve estable (7.x), el equipo se compromete a dar soporte (correcciones importantes de errores) a la versión anterior (6.x) durante varios meses, para dar a los creadores tiempo suficiente para migrar. La duración se determina caso por caso, dependiendo del esfuerzo de migración requerido.

Versiones pre-lanzadas

Siempre es posible acceder a las adiciones más recientes al framework de scripting instalando la @next versión del @dcl/sdk paquete en una escena.

Las características en esta rama pueden ser inestables o no estar documentadas, ya que no se publican como parte de una versión del SDK oficialmente soportada.