Compute Engine ganha multi-versioning de API com versões por data e mantém a /v1 estável

O Compute Engine trocou o modelo de versionamento por canais (CBV, com /v1, /beta e /alpha) pelo versionamento baseado em interface (IBV), alinhado ao Google AIP-185. O problema era a /v1 ser uma superfície única e mutável, compartilhada por todos os clientes. Mudar um default ou modernizar um formato de erro podia quebrar scripts ou exigir migrações de vários anos.

Agora existem snapshots imutáveis por data ao lado da /v1. As stable (YYYY-MM-DD) saem a cada trimestre, a partir de 1 de setembro de 2026, e não recebem breaking changes depois de publicadas. As preview (YYYY-MM-DD-preview, como 2026-10-01-preview) derivam de uma stable e duram um ano. A versão alvo vai no header X-Goog-Api-Version ou no parâmetro $apiVersion, e o caminho base continua /compute/v1/, então os selfLink dos recursos seguem uniformes. Entre os novos comportamentos das versões por data: returnPartialSuccess habilitado por padrão em AggregatedList, erros no formato google.rpc.ErrorInfo (AIP-193) e checagens de IAM menos amplas. A /v1 continua como padrão quando nenhuma versão é informada.

Para quem opera pipelines e módulos de IaC sobre o Compute Engine, a leitura é que fixar uma versão por data vira uma forma de tratar a API como dependência com lock. O teste em staging passa a ser a troca de uma string, e o rollout fica no seu ritmo. Vale já revisar código que faz parse de mensagens de erro por regex e consultas globais que dependiam do comportamento antigo de falha total, porque são os pontos onde os defaults novos podem aparecer ao migrar.