> 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-pt/scenes-sdk7/referencia-da-api/version-support-agreement.md). # Acordo de suporte à versão Este documento descreve a política de versionamento aplicada tanto ao Scene Editor no Creator Hub quanto ao framework de scripting (o `@dcl/sdk` pacote). O objetivo desta política de versionamento é forjar um contrato entre a equipa de SDK da Decentraland Foundation e os criadores de conteúdo, para estabelecer expectativas claras e permitir que os criadores de conteúdo planeiem o seu trabalho em conformidade. ## Definições * *Número de versão* -- um identificador único para uma versão de software disponível publicamente. Este identificador consiste num *número da versão major* e num *número da versão minor* separados por pontos (por exemplo, 7.2). * *Família de versões* -- todas as versões que têm a mesma major version formam uma família. Chamamos a versão A de *sucessora* da versão B se A e B pertencerem à mesma família e o número minor de A for superior ao de B (por exemplo, 7.11 é sucessora de 7.10). * *Alteração incompatível* -- uma alteração que obriga um utilizador a mudar o seu código ou assets para os manter em estado funcional. Por exemplo, uma propriedade muda de nome e obriga o utilizador a alterar esse nome de propriedade sempre que é usada em todo o seu código. * *Alteração compatível* -- uma alteração que não requer qualquer ação por parte do utilizador. O comportamento e as propriedades do código e dos assets do utilizador permanecem inalterados. * *Versão estável* -- uma versão que proíbe alterações incompatíveis em todos os seus sucessores (que são todos também considerados estáveis). Qualquer alteração incompatível deve ser introduzida apenas através da criação de uma nova família de versões, incrementando o número da versão major; no entanto, consulte a ressalva na secção de [alterações incompatíveis](#breaking-changes) . As alterações compatíveis são refletidas através do incremento do número da versão minor. * *Versão instável* -- uma versão que permite alterações incompatíveis nos seus sucessores. As alterações incompatíveis podem ser introduzidas incrementando o número da versão minor. ## Política de suporte Em cada família de versões estáveis, a Decentraland Foundation suporta apenas a versão minor mais recente. Em qualquer momento, deve haver no máximo duas famílias suportadas. Por exemplo, se a versão minor mais recente da família 6.x for 6.11 e a versão minor mais recente da família 7.x for 7.3, espera-se que os criadores de conteúdo desenvolvam as suas scenes em 6.11 ou 7.3. As scenes que foram desenvolvidas e publicadas com a versão 6.10 ou anterior muito provavelmente continuarão a funcionar e os jogadores poderão apreciá-las. No entanto, se essas scenes mais antigas tiverem algum problema, devem primeiro ser atualizadas para uma versão suportada, e o problema só será investigado se continuar a ocorrer numa versão suportada. O Scene Editor atualiza automaticamente o pacote de scripting de todas as scenes dentro da mesma família de versões, para que todos os developers usem a versão suportada mais recente ao desenvolver as suas scenes. ## Desenvolvimento de funcionalidades As novas funcionalidades serão lançadas apenas na versão mais recente em desenvolvimento. Assim que a equipa de desenvolvimento começar a trabalhar numa nova família de versões, as famílias de versões mais antigas que continuem com suporte receberão apenas correções importantes de bugs, e não serão implementadas funcionalidades adicionais. ## Alterações incompatíveis As alterações incompatíveis devem ocorrer apenas em lançamentos major. Não deve haver alterações incompatíveis nas versões minor estáveis da mesma família de versões, exceto em caso de emergência, quando não existirem outros meios para resolver o problema. Alterações incompatíveis dentro de um lançamento minor são uma medida drástica que os developers evitarão a todo o custo. Novos lançamentos minor irão expandir as capacidades da sintaxe existente, mas nunca devem alterar o que a sintaxe estabelecida produz, exceto quando corrigem bugs. ### Alterações isoladas Em ocasiões muito raras, pode ser preferível fazer uma pequena alteração incompatível e isolada se isso só incomodar um pequeno subconjunto de utilizadores. (Criar uma nova versão major incomoda todos os utilizadores.) Neste caso, o SDK pode descontinuar uma funcionalidade, mas deve continuar a suportá-la durante um período de tempo razoável. ### Alterações de emergência Em certos casos excecionais, como preocupações de segurança ou requisitos regulamentares, qualquer funcionalidade pode ser alterada de forma incompatível, independentemente do seu nível de estabilidade, e, nestas situações, não é prometida uma descontinuação. ## Lançamentos estáveis e instáveis ### Alpha Sempre que é introduzido um novo lançamento major, alguns dos primeiros lançamentos minor podem ser identificados como instáveis **alpha** versões. As alterações incompatíveis devem ser permitidas e esperadas em lançamentos alpha, e os utilizadores não devem ter qualquer expectativa de estabilidade. Os developers são livres para experimentar estas versões alpha, mas não são incentivados a publicar conteúdo construído com versões alpha instáveis, pois não há garantia de que o conteúdo continuará a funcionar após alterações subsequentes. Também não é recomendado iniciar grandes migrações complexas nesta fase, uma vez que podem ser necessárias mais alterações antes do próximo lançamento estável. ### Beta Quando uma família de versões atinge um determinado nível de maturidade, é disponibilizado um lançamento **beta** . Um lançamento beta é considerado concluído e pronto para ser declarado estável, sujeito a testes públicos. As famílias de versões beta devem ser o mais estáveis possível; no entanto, é permitido que mudem ao longo do tempo. Estas alterações devem ser mínimas, mas podem incluir alterações incompatíveis. As alterações incompatíveis só podem ser introduzidas após um período razoável de descontinuação, para dar aos criadores de conteúdo a oportunidade de migrar as suas scenes. Esse período de descontinuação deve ser definido quando a alteração incompatível for introduzida. As famílias de versões beta devem permanecer em beta apenas por um período limitado, especificado no momento em que são marcadas como beta. Devem passar para estável se não forem encontrados problemas nesse período. A duração deste período pode variar caso a caso, mas uma boa regra prática é 90 dias. O conteúdo escrito com a sintaxe de uma versão beta deve ser fácil de migrar para versões posteriores dentro dessa mesma família. Ainda não é aconselhável desenvolver conteúdo para eventos importantes com uma versão beta, uma vez que os testes ainda estão em curso e é provável que existam bugs. ### Estável Quando o período beta termina sem problemas significativos, a família de versões é considerada **estável** e não deve haver mais alterações à sintaxe, para além da adição de novas funcionalidades. A partir deste ponto, a versão é considerada a opção recomendada e incentivada para todos os developers usarem. Uma família de versões estável deve ser totalmente suportada durante todo o seu ciclo de vida. Não deve haver alterações incompatíveis, sujeito às ressalvas descritas abaixo. ## Funcionalidades instáveis em lançamentos estáveis Funcionalidades específicas num lançamento podem ter níveis de estabilidade diferentes do lançamento como um todo. Isto pode acontecer porque a funcionalidade foi introduzida recentemente e requer mais testes, ou porque está destinada a ser substituída em breve. Por exemplo, um novo tipo de component poderia ser introduzido como alpha numa release já estável do framework do SDK, uma vez que esse component específico pode ainda necessitar do seu próprio ciclo de testes. Pode então seguir o fluxo de versionamento descrito acima, passando de alpha para beta e depois para stable. Qualquer funcionalidade de um lançamento estável que não seja considerada estável deve ser claramente identificada como tal na documentação. Os criadores que utilizem funcionalidades instáveis devem estar cientes de que a funcionalidade poderá sofrer alterações incompatíveis. Quaisquer alterações incompatíveis serão comunicadas de forma clara, incluindo guias de migração, e haverá um período de transição para que os criadores ajustem o código da sua scene. ## Durante quanto tempo suportamos uma família de versões estável? Quando uma nova família de versões se torna estável (7.x), a equipa compromete-se a dar suporte (correções importantes de bugs) à versão anterior (6.x) durante vários meses, para dar aos criadores tempo suficiente para migrar. A duração é determinada caso a caso, dependendo do esforço de migração necessário. ## Versões pré-lançadas É sempre possível aceder às adições mais recentes ao framework de scripting instalando a `@next` versão do `@dcl/sdk` pacote numa scene. As funcionalidades nesta branch podem ser instáveis ou não documentadas, uma vez que não são disponibilizadas como parte de uma versão oficialmente suportada do SDK. --- # 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-pt/scenes-sdk7/referencia-da-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.