Como versionamos atalhos quando um software muda: DaVinci Resolve 20 → 21

1. “Atualizar a lista” parece simples até existir histórico

Se um site mantém só a versão atual de um software, trocar o conteúdo é fácil. O problema aparece quando alguém ainda usa a versão anterior, um link antigo aponta para um comando específico ou uma busca inclui explicitamente o número da versão.

Apagar a versão 20 faria uma pesquisa por “atalho DaVinci Resolve 20” cair numa página da versão 21. Duplicar manualmente centenas de registros, por outro lado, criaria duas bases quase iguais que poderiam divergir a cada correção.

2. Primeiro comparamos os presets, não a aparência da interface

O catálogo do Resolve é baseado nos atalhos presentes no preset padrão exportado. Na comparação 20 → 21, confirmamos 442 comandos com atalho na versão 20 e 466 na versão 21.

Dos comandos do conjunto anterior, 440 mantiveram o mesmo binding, 2 foram remapeados, 24 comandos com atalho foram adicionados e nenhum comando com atalho do conjunto anterior foi removido.

Os dois remapeamentos ajudam a mostrar por que o número da versão importa: Project Manager mudou de Shift+1 para Shift+0, e a página Media mudou de Shift+2 para Shift+1. O Resolve 21 passou a usar Shift+2 para a nova página Photo.

3. Em vez de duas cópias, mantemos uma base e um delta

A arquitetura da V2.3 usa os dados do Resolve 20 como base auditável e um arquivo de delta para descrever somente o que a versão 21 altera. Esse delta contém exatamente os 2 overrides e as 24 adições confirmadas.

Um script deriva os catálogos finais a partir dessas peças. Assim, uma correção em um comando que existe nas duas versões pode ser tratada na base, enquanto uma mudança exclusiva da versão nova continua isolada no delta.

Isso é importante porque “não repetir dados” aqui não é só preferência de desenvolvedor: reduz a chance de o usuário encontrar duas respostas diferentes para um comando que deveria ser o mesmo.

4. A versão atual fica na URL limpa; a anterior ganha URL explícita

No Atalhos, /davinci-resolve representa a versão atual, hoje o Resolve 21. A versão anterior continua disponível em /davinci-resolve-20. As duas páginas têm canonical próprio e seletor de versão.

Essa decisão mantém a URL principal simples para quem só quer “DaVinci Resolve”, mas preserva uma resposta específica para quem precisa da versão 20. Deep links legados importantes também foram mantidos para não quebrar referências existentes.

5. A busca genérica precisa preferir o presente sem esconder o passado

Se as duas versões fossem jogadas no mesmo índice sem regra, uma busca por “dividir davinci” poderia devolver resultados duplicados. A V2.3 trata a versão 21 como padrão e só traz a versão arquivada quando o usuário pede explicitamente Resolve 20 ou escolhe essa versão no filtro.

Na prática: “dividir davinci” aponta para a versão atual; “dividir davinci 20” encontra a histórica. Assim o histórico existe sem virar ruído.

6. O versionamento é verificado por teste, não por memória

O QA da V2.3 confere automaticamente os totais das duas versões, a quantidade exata de adições, remoções e remapeamentos, comandos críticos, busca genérica, pesquisa explícita da versão histórica, canonicals, sitemap e redirects.

Além disso, as páginas das duas versões passaram por inspeção renderizada em desktop e mobile para verificar seletor, buscas internas e overflow. A parte visual não substitui a validação dos dados; são duas camadas diferentes de qualidade.

7. A lição serve para qualquer catálogo versionado

Quando uma base muda pouco entre versões, copiar tudo é desperdício e sobrescrever tudo perde história. Uma estratégia de base + diferenças funciona bem quando as mudanças podem ser identificadas de maneira determinística.

Também aprendemos que “versão atual” e “versão pesquisada” são intenções diferentes. O usuário que não especifica versão provavelmente quer o software atual; quem escreve “20” está dando um sinal que o produto deve respeitar.