Acordo de Suporte de Versão

acordo de suporte de 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 é estabelecer um contrato entre a equipe do SDK da Decentraland Foundation e os criadores de conteúdo, definir expectativas claras e permitir que os criadores planejem seu trabalho de acordo.

Definições

• Número da versão -- um identificador único para uma versão publicamente disponível de software. Este identificador consiste em uma versão major e um versão minor número, separados por pontos (por exemplo, 7.2).

• Família de versões -- todas as versões que têm o mesmo número major formam uma família. Chamamos a versão A de sucessora da versão B se A e B pertencem à mesma família e o número minor de A é maior que o de B (por exemplo, 7.11 é sucessora de 7.10).

• Mudança breaking -- uma mudança que obriga um usuário a alterar seu código ou ativos para mantê-los em funcionamento. Por exemplo, uma propriedade muda de nome e força o usuário a alterar esse nome de propriedade toda vez que é usado no código.

• Mudança non-breaking -- uma mudança que não exige qualquer ação por parte do usuário. O comportamento e as propriedades do código e dos ativos do usuário permanecem inalterados.

• Versão estável -- uma versão que proíbe mudanças breaking em todas as suas sucessoras (as quais também são consideradas estáveis). Qualquer mudança breaking 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; contudo, veja a ressalva na mudanças breaking seção. Mudanças non-breaking são refletidas através do incremento do número minor.

• Versão instável -- uma versão que permite mudanças breaking em suas sucessoras. Mudanças breaking podem ser introduzidas incrementando o número minor.

Política de suporte

Em cada família de versões estável, a Decentraland Foundation suporta apenas a última versão minor. A qualquer momento, deve haver no máximo duas famílias suportadas.

Por exemplo, se a última versão minor da família 6.x é 6.11, e a última versão minor da família 7.x é 7.3, espera-se que os criadores de conteúdo desenvolvam suas cenas em 6.11 ou 7.3. Cenas desenvolvidas e publicadas com a versão 6.10 ou anterior provavelmente continuarão funcionando e os jogadores poderão aproveitá-las. No entanto, se essas cenas mais antigas apresentarem algum problema, elas devem primeiro ser atualizadas para uma versão suportada, e o problema só será investigado se ainda ocorrer em uma versão suportada.

O Scene Editor atualiza automaticamente o pacote de scripting de todas as cenas dentro da mesma família de versões, para que todos os desenvolvedores usem a versão suportada mais recente ao desenvolver suas cenas.

Desenvolvimento de recursos

Novos recursos serão lançados apenas na versão mais recente em desenvolvimento. Assim que a equipe de desenvolvimento iniciar o trabalho em uma nova família de versões, famílias de versões mais antigas que permanecem em suporte receberão apenas correções de bugs importantes, e nenhum recurso adicional será implementado.

Mudanças breaking

Mudanças breaking devem ocorrer apenas em lançamentos major. Não deve haver mudanças breaking dentro dos lançamentos minor estáveis da mesma família de versões, exceto em caso de emergência quando não há outros meios para resolvê-la. Mudanças breaking dentro de um release minor são uma medida drástica que os desenvolvedores evitarão a todo custo. Novos releases minor devem estender as capacidades da sintaxe existente, mas nunca devem alterar o que a sintaxe estabelecida produz, exceto ao corrigir bugs.

Mudanças isoladas

Em ocasiões muito raras, pode ser preferível fazer uma pequena mudança breaking isolada se isso incomodar apenas um pequeno subconjunto de usuários. (Criar uma nova versão major incomoda todos os usuários.) Nesse caso, o SDK pode depreciar um recurso, mas deve continuar a suportá-lo por um período razoável de tempo.

Mudanças de emergência

Em certos casos excepcionais, como preocupações de segurança ou exigências regulatórias, qualquer recurso pode ser alterado de forma breaking independentemente do seu nível de estabilidade, e uma depreciação não é prometida nessas situações.

Lançamentos estáveis e instáveis

Alpha

Sempre que um novo lançamento major é introduzido, alguns releases minor iniciais podem ser rotulados como instáveis alpha versões. Mudanças breaking devem ser permitidas e esperadas em releases alpha, e os usuários não devem ter expectativa de estabilidade.

Os desenvolvedores são livres para experimentar com essas versões alpha, mas não é encorajado publicar conteúdo construído com versões alpha instáveis, pois não há garantia de que o conteúdo continuará funcionando após mudanças subsequentes. Também não é recomendado iniciar grandes migrações complexas neste ponto, pois mais mudanças podem ser necessárias antes do próximo lançamento estável.

Beta

Uma vez que uma família de versões atinge um certo nível de maturidade, é disponibilizado um beta release. Um release beta é considerado completo e pronto para ser declarado estável, sujeito a testes públicos.

Famílias de versões beta devem ser o mais estáveis possível; contudo, elas podem mudar ao longo do tempo. Essas mudanças devem ser mínimas, mas podem incluir mudanças breaking. Mudanças breaking só podem ser introduzidas após um período razoável de depreciação para dar aos criadores de conteúdo a oportunidade de migrar suas cenas. Esse período de depreciação deve ser definido quando a mudança breaking for introduzida.

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 ser promovidas a estáveis se nenhum problema for encontrado nesse período. A duração desse período pode variar caso a caso, mas uma boa regra prática é 90 dias.

Conteúdo escrito com a sintaxe de uma versão beta deve ser fácil de migrar para versões posteriores dentro dessa família. Ainda não é aconselhável desenvolver conteúdo para eventos principais com uma versão beta, pois os testes ainda estão em andamento e bugs são prováveis.

Estável

Uma vez que o período beta termine sem problemas maiores, a família de versões é considerada estável e não deve haver mais mudanças na sintaxe, além da adição de novos recursos. A partir deste ponto, a versão é considerada a opção recomendada e encorajada para todos os desenvolvedores usarem.

Uma família de versões estável deve ser totalmente suportada ao longo de sua vida útil. Não deve haver mudanças breaking, sujeito às ressalvas descritas abaixo.

Recursos instáveis em lançamentos estáveis

Recursos específicos em um release podem ter níveis de estabilidade diferentes do release como um todo. Isso pode acontecer porque o recurso foi recentemente introduzido e requer mais testes, ou porque está destinado a ser substituído em breve.

Por exemplo, um novo tipo de componente pode ser introduzido como alpha em um release do SDK já estável, já que esse componente em particular ainda pode requerer seu próprio ciclo de testes. Ele então pode seguir o fluxo de versionamento descrito acima, passando de alpha para beta e depois para estável.

Qualquer recurso de um release estável que não seja considerado estável deve ser claramente rotulado como tal na documentação. Criadores que utilizam recursos instáveis devem estar cientes de que o recurso pode sofrer mudanças breaking. Quaisquer mudanças breaking 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 de suas cenas.

Por quanto tempo suportamos uma família de versões estável?

Uma vez que uma nova família de versões se torne estável (7.x), a equipe se compromete a suportar (correções de bugs major) a versão anterior (6.x) por 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 exigido.

Versões pré-lançadas

Sempre é possível acessar as adições mais recentes ao framework de scripting instalando a @next versão do @dcl/sdk pacote em uma cena.

Os recursos neste branch podem ser instáveis ou não documentados, pois não são enviados como parte de uma versão oficialmente suportada do SDK.