...
Major:
Contempla alterações de especificações derivadas de grandes lançamentos planejados pelo GT baseados nas prioridades do ecossistema e do Banco Central;
Contêm grandes mudanças de arquitetura ou de escopo como inclusão de novos arranjos de pagamento e atualizações na máquina de estados;
Pode conter várias dessas mudanças agrupadas;
Não possui restrição quanto aos tipos de alterações existentes;
Permite todas as alterações não aceitas nos versionamentos minor e patch;
Exemplos: v1.0.0, v2.0.0
Minor:
Permite alterações com quebra de contrato nos casos de correção de bugs que estejam impactando negativamente o ecossistema e adequações regulatórias que não podem aguardar o próximo versionamento major;
Permite adição de novas funcionalidades, desde que não haja quebra de contrato;
Para toda proposta de alteração minor, deve ser feita uma análise de risco/retorno pelo GT responsável, pois o versionamento minor subentende um processo de testes simplificado, se comparado à major;
Permite ajustes (adição, alteração, exclusão) para valores dos campos do tipo ENUM, mesmo que haja quebra de contrato, sendo necessário análise de risco/retorno pelo GT responsável;
Exemplos: v1.1.0, v1.2.0
Patch:
Contempla alterações de documentação para promover esclarecimentos no texto ou correções feitas no Swagger que não impactam em nada na funcionalidade das APIs;
Permite alterações sem quebra de contrato no caso de correções de bugs ou cenários específicos que não demandem implementação por todos os participantes do ecossistema;
Exemplos: v1.1.1, v1.1.2
...
Dentro de um mesmo estágio: 1.0.0-beta.1 ➞ 1.0.0-beta.2;
Entre estágios :2.0.0-beta.4 ➞ 2.0.0-rc.1;
Entre versões: 4.0.0 ➞ 4.1.0.
...
Definição sobre período de convivência de acordo com o tipo de versionamento
Versionamento | Restrições |
|---|
Versão de referência (nova)
Nova versão da API (Current) | Versão anterior da API (Deprecated) | |||
|---|---|---|---|---|
Possui data limite para implementação | Necessita certificação | Depreciação | Aposentadoria | |
Retired) | Observação | |||||
Major | Não haverá mais do que duas versões em convivência |
| Sim | 90 dias contados a partir do início em produção da nova versão em casos em que não houver período de piloto. | Acontecerá quando terminar o período de convivência, ficando vigente apenas a nova versão major | N/A |
Minor Planejada | Não haverá breaking change |
| Sim, processo simplificado | Não haverá período de convivência | Aposentadoria imediata | Não há problemas de interoperabilidade |
Minor Crítica Não Sincronizada¹ | Necessidade de implementar o mais breve possível até a data limite estabelecida, porém os participantes não precisam sincronizar o momento do início em produção |
| Sim, processo simplificado | Não haverá período de convivência | Aposentadoria imediata | Não gerar novos problemas de interoperabilidade para quem consome e a aplicação das soluções pelas instituições podem ocorrer até a data limite para implementação estabelecida em informa. |
Minor Crítica Sincronizada | Necessidade de implementar o mais breve possível, porém os participantes devem sincronizar o momento do início em produção |
| Sim, processo simplificado | Não haverá período de convivência | Aposentadoria imediata | Há riscos de novos problemas de interoperabilidade para quem consome e a implementação em produção deve ser sincronizada na data e hora estabelecida em informa |
Patch | N/A |
| Não | Não haverá período de convivência | Aposentadoria imediata | N/A |
Legenda:
1- Sincronizada: Início em produção realizado ao mesmo tempo por todos os participantes;
2- Fornecedores: Detentoras de conta e transmissoras de dados;
3- Consumidores: Iniciadoras de pagamento e receptoras de dados.