...
A alteração dos dados de uma API para cada mudança de versão Status, devem deverão ser consideradas como regras gerais:
A API deverá conter uma ÚNICA versão
Current. Exceto, para um novo produto DEVERÁ conter um ÚNICO StatusCurrent, EXCETO para um NOVO PRODUTO, tendo em vista que não existem versões anteriores;Se o versionamento de uma API for do tipo Patch
PATCH, as datas de início e fim para os status Status deCertifyingouDeprecatedpodem ser nulas (NULL), tendo em vista que não há um período de convivência.As datas de início e fim do Status NÃO DEVERÃO ser IDÊNTICAS, EXCETO para os Status de
Retired.
Além disso, o preenchimento das datas de inicio e fim devem seguir as especificações abaixo, de acordo com as mudanças de status Status:
STATUS | DATA DE INÍCIO | DATA FIM |
Toda versão Todo Status | Data da divulgação da primeira versão da especificação (beta.0) | Dia do primeiro marco |
Toda versão Todo Status | Data da divulgação da especificação (beta.0) | Data do go-live |
Toda versão Todo Status | Dia do primeiro marco | Fim do período do processamento de pedidos de certificação |
Toda versão Todo Status | Data do go-live |
|
Toda versão Todo Status | Data do go-live | Último dia do período convivência |
Toda versão Todo Status | Data do go-live | Dia do go-live da nova versão |
Toda versão Todo Status | Data do go-live | Último dia do período de convivência |
Toda versão Todo Status |
|
|
Toda versão Todo Status | Último dia do período convivência | Último dia do período convivência |
Toda versão Todo Status | Dia do go-live da nova versão | Dia do go-live da nova versão |
...