Afim de proporcionar a abrangência do range de versões de plugins e actions dentro da stack e starter, para isso utilizaremos a convenção semver da padronização de versionamento. O objetivo dessa etapa está centrada em resolver dores específicas de usuários no que diz respeito ao fato que atualmente quando uma nova versão de plugin / action é publicada não gera uma nova versão da stack automaticamente, sendo trabalhoso atualizar um plugin em uma stack. Além dissso, quando gera uma stack nova não é atualizado os workspaces. Sendo assim, vamos trabalhar para que essa feature resolva as dores elencadas anteriormente e proporcione para os nossos usuários uma experiência mais fluida dentro da plataforma.
Seguir a convenção semver da padronização de versionamento que NPM implementa.
Definições:
Dentro de uma release major não poderia ter mudanças de contrato de connection interface e nem de inputs para não quebrar o contexto de inputs e de infra setup. Content precisa validar na publicação de uma nova release. Ou seja, quando tiver alguma mudança de contrato ele precisa gerar uma nova versão da stack e adicioná-la ao workspace.
Não irá existir o recurso de adicionar qualquer versão de um determinado conteúdo na stack ou em um workspace, é necessário estar vinculado a pelo menos a uma versão major, podendo variar o minor e/ou patch. (Exemplo: adicionar uma versão de plugin na stack 2.x.x, se tiver que lançar a versão 3 tem que fazer o processo manual como é hoje (item anterior)).
Não tem atualização automática de aplicação/infra que já estejam criadas, terá apenas uma notificação que contém conteúdo desatualizado. (jornada precisa ser desenhada).
Domínios impactados
Front: adição de um plugin ou action em uma stack porque agora tem que selecionar uma versão compatível àquela stack, além disso tem que mudar no workspace.
Content: grande impacto em fazer a mecânica de stack não ser mais domínio fixo de versão e permitir o intervalo de versões.
Workspace: impacto médio em exibir a versão que foi criada ou atualizada.
CLI: impacto grande para buscar as últimas versões conforme indicação da stack (por exemplo, 1 - Se a stack aceita uma versão 1.1.x deverá baixar a última patch (ex. 1.1.22). 2 - Se o plugin de uma stack aceita um versão 1.x.x deverá baixar a última minor (ex. 1.3.2))
Definition Of Done
[ ] Eu, como criador de conteúdo, quero ter a possibilidade de escolher dentro da stack e starter a versão de plugin / action dentro de um range de acordo com a padronização de versionamento semver.
[ ] Eu, como criador de conteúdo, quero que minha stack permita o range de versões selecionadas sem precisar criar uma nova stack para incluir plugins atualizados e pertencentes ao range.
[ ] Eu, como consumidor de conteúdo, quero que minhas stacks adicionadas em workspace estejam automaticamente atualizadas de acordo com o range de versão de plugin/action selecionados no estúdio.
Descrição
Afim de proporcionar a abrangência do range de versões de plugins e actions dentro da stack e starter, para isso utilizaremos a convenção semver da padronização de versionamento. O objetivo dessa etapa está centrada em resolver dores específicas de usuários no que diz respeito ao fato que atualmente quando uma nova versão de plugin / action é publicada não gera uma nova versão da stack automaticamente, sendo trabalhoso atualizar um plugin em uma stack. Além dissso, quando gera uma stack nova não é atualizado os workspaces. Sendo assim, vamos trabalhar para que essa feature resolva as dores elencadas anteriormente e proporcione para os nossos usuários uma experiência mais fluida dentro da plataforma.
Artefatos
FigJam Design
Figma UX Telas
Figma UX Navegável
Design Doc
Solução
Definições:
Domínios impactados
Definition Of Done