> For the complete documentation index, see [llms.txt](https://docs.decentraland.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.decentraland.org/creator/content-creator-es/escenas-sdk7/referencia-de-api/version-support-agreement.md). # 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` package). El objetivo de esta política de versionado es establecer un contrato entre el equipo de SDK de la Decentraland Foundation y los creadores de contenido, para fijar 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 un *número de versión mayor* y un *número de versión menor* , separados por puntos (por ejemplo, 7.2). * *Familia de versiones* -- todas las versiones que tienen la misma versión mayor forman una familia. Llamamos a la versión A un *sucesor* de la versión B si A y B pertenecen a la misma familia y el número menor de A es más alto que el de B (por ejemplo, 7.11 es un sucesor de 7.10). * *Cambio incompatible* -- un cambio que obliga a un usuario a cambiar su código o sus assets para mantenerlos en un 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 todo su código. * *Cambio compatible* -- un cambio que no requiere ninguna acción por parte de un usuario. El comportamiento y las propiedades del código y los assets del usuario permanecen sin cambios. * *Versión estable* -- una versión que prohíbe los cambios incompatibles en todos sus sucesores (que también se consideran estables). Cualquier cambio incompatible debe introducirse solo mediante la creación de una nueva familia de versiones al incrementar el número de versión mayor; sin embargo, consulta la advertencia en la sección de [cambios incompatibles](#breaking-changes) . Los cambios compatibles se reflejan incrementando el número de versión menor. * *Versión inestable* -- una versión que permite cambios incompatibles en sus sucesores. Los cambios incompatibles pueden introducirse incrementando el número de versión menor. ## Política de soporte En cada familia de versiones estables, la Decentraland Foundation solo da soporte a la última versión menor. En cualquier momento dado debe haber como máximo dos familias con soporte. 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. Es muy probable que las escenas que se desarrollaron y publicaron con la versión 6.10 o anterior sigan funcionando y que los jugadores puedan disfrutarlas. Sin embargo, si estas escenas más antiguas experimentan algún problema, primero deben actualizarse a una versión con soporte, y el problema solo se investigará si sigue ocurriendo en una versión con soporte. El Scene Editor actualiza automáticamente el package de scripting de todas las escenas dentro de la misma familia de versiones, para que todos los desarrolladores usen la última versión con soporte al desarrollar sus escenas. ## Desarrollo de funciones Las nuevas funciones solo se lanzarán en la última versión en desarrollo. En cuanto el equipo de desarrollo comience a trabajar en una nueva familia de versiones, las familias de versiones anteriores que sigan teniendo soporte solo recibirán correcciones de errores importantes, y no se implementarán funciones adicionales. ## Cambios incompatibles Los cambios incompatibles solo deberían ocurrir en versiones mayores. No debería haber cambios incompatibles dentro de las versiones menores estables de la misma familia de versiones, excepto en caso de emergencia, cuando no haya otros medios para resolverlo. Los cambios incompatibles dentro de una versión menor son una medida drástica que los desarrolladores evitarán a toda costa. Las nuevas versiones menores ampliarán las capacidades de la sintaxis existente, pero nunca deberían cambiar lo que produce la sintaxis establecida, salvo al corregir errores. ### Cambios aislados En ocasiones muy poco frecuentes, puede ser preferible hacer un pequeño cambio incompatible aislado si solo va a incomodar a un pequeño subconjunto de usuarios. (Crear una nueva versión mayor incomoda a todos los usuarios.) En este caso, el SDK podría declarar obsoleta una función, pero debe seguir dándole soporte durante un período de tiempo razonable. ### Cambios de emergencia En ciertos casos excepcionales, como problemas de seguridad o requisitos normativos, cualquier función puede cambiar de forma incompatible independientemente de su nivel de estabilidad, y en estas situaciones no se promete una declaración de obsolescencia. ## Lanzamientos estables e inestables ### Alpha Siempre que se introduce un nuevo lanzamiento mayor, algunos lanzamientos menores iniciales pueden etiquetarse como versiones **alpha** inestables. Los cambios incompatibles deben permitirse y esperarse en los lanzamientos alpha, y los usuarios no deben tener ninguna expectativa de estabilidad. Los desarrolladores son libres de experimentar con estas versiones alpha, pero no se les recomienda publicar contenido construido con versiones alpha 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 puede que sean necesarios más cambios antes del próximo 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 declararse estable, sujeto a pruebas públicas. Las familias de versiones beta deberían ser lo más estables posible; sin embargo, se permite que cambien con el tiempo. Estos cambios deberían ser mínimos, pero pueden incluir cambios incompatibles. Los cambios incompatibles solo pueden introducirse después de un período razonable de declaración de obsolescencia, para dar a los creadores de contenido la oportunidad de migrar sus escenas. Este período de obsolescencia debe definirse cuando se introduzca el cambio incompatible. Las familias de versiones beta solo deberían permanecer en beta durante un período de tiempo limitado, especificado en el momento de marcarlas como beta. Deberían promoverse a estables si no se encuentran problemas durante ese período. La duración de este período puede variar caso por caso, pero una buena regla general es 90 días. El contenido escrito con la sintaxis de una versión beta debería ser fácil de migrar a versiones posteriores dentro de esa familia. Aun así, no es aconsejable desarrollar contenido para eventos importantes con una versión beta, ya que las pruebas siguen en progreso y es probable que haya errores. ### Estable Una vez que el período de beta termina sin problemas importantes, la familia de versiones se considera **estable** y no debería haber más cambios en la sintaxis, salvo la incorporación de nuevas funciones. A partir de este momento, la versión se considera la opción recomendada y animada para que la usen todos los desarrolladores. Una familia de versiones estables debe contar con soporte completo durante todo su ciclo de vida. No debe haber cambios incompatibles, sujeto a las advertencias descritas a continuación. ## Funciones inestables en lanzamientos estables Algunas funciones específicas de un lanzamiento pueden tener niveles de estabilidad diferentes del lanzamiento en su conjunto. Esto puede deberse a que la función se ha introducido recientemente y requiere más pruebas, o a que está destinada a ser reemplazada pronto. Por ejemplo, un nuevo tipo de componente podría introducirse como alpha en un lanzamiento ya estable del framework del SDK, ya que este componente en particular podría seguir requiriendo su propio ciclo de pruebas. Después podría seguir el flujo de versionado descrito arriba, pasando de alpha a beta y luego a estable. Cualquier función de un lanzamiento estable que no se considere estable debe etiquetarse claramente como tal en la documentación. Los creadores que hagan uso de funciones inestables deben ser conscientes de que la función podría sufrir cambios incompatibles. Cualquier cambio incompatible se comunicará claramente, incluidas las guías de migración, y habrá un período de transición para que los creadores ajusten el código de su escena. ## ¿Durante cuánto tiempo damos soporte a una familia de versiones estables? Una vez que una nueva familia de versiones se vuelve estable (7.x), el equipo se compromete a dar soporte (correcciones de errores importantes) a la versión anterior (6.x) durante varios meses, para dar a los creadores tiempo de sobra para migrar. La duración se determina caso por caso, según el esfuerzo de migración requerido. ## Versiones de prelanzamiento Siempre es posible acceder a las incorporaciones más recientes al framework de scripting instalando la `@next` versión del `@dcl/sdk` package en una escena. Las funciones de esta rama pueden ser inestables o no estar documentadas, ya que no se publican como parte de una versión del SDK oficialmente compatible. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.decentraland.org/creator/content-creator-es/escenas-sdk7/referencia-de-api/version-support-agreement.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.