Closed JuanBarros2 closed 5 years ago
@JuanBarros2 eu dei uma ohada, mas me pareceu que é muito sobre versionamento de código, no caso dos endpoints, tu tem alguma sugestão de como manter disponível as diferentes versões da API? (pelo menos por um tempo de sla, alguns meses pra dar tempo de migrar)
Sim, é muito sobre versionamento. Acho que poderia ser usado o sistema de tags e release do github. Nele é possível criar versões para o repositório a partir de uma tag. Dessa forma, poderia ser colocado um prazo de alguns dias para ir adicionar código em desenvolvimento e fosse sendo adicionado as modificações ao fim desse prazo. O bom é que essa ferramenta prevê uma descrição que poderia ser as endpoints alteradas e isso tudo ficaria documentado dentro do próprio repositório. Além disso, dá pra criar tags "draft" em que você marca o dia para acabar as alterações da versão. Vale a pena dar uma olhada, @JoseRenan
Outra coisa que poderia ajudar também é colocar um arquivo de changelog https://keepachangelog.com/pt-BR/0.3.0/
Simmm, um CHANGELOG é top msm, sobre o versionamento, a gente podia definir o modelo: X.Y.Z, sendo Z a adição de coisas que não interferem no código existente (em retrocompatibilidade), Y se corrigir um bug que não interfere em retrocompatibilizade e X se mudar a interface de alguma coisa (interferir na retrocompatibilidade de alguma forma)... daí no caso, temos a pasta v1, só criaríamos a v2 em caso de mudar o X, e o changelog é alterado a cada nova tag independente de ter mudado X,Y ou Z
Referenciado aqui #36 . Estou fechando por conta da reestruturação do laguinho #31
Encontrei uma forma de tag'ar as versões de um repositório de acordo com as interfaces que são providas por ela. Especialmente por se tratar de uma API Rest, acredito que seria ótimo seguir esse sistema de versionamento para que usuários não se percam em versões que não contemplem a mesma interface de interação com a API e isso seria ótimo para especificar as alterações e melhorias que teríamos em cada versão do projeto.