Lendo changelogs antes de atualizar três dependências desatualizadas

A mesma revisão do repositório que encontrou nenhum escaneamento de dependências também sinalizou três dependências específicas no Cargo.toml do Greenhouse como desatualizadas: serde_yaml 0.9 está arquivado e sem manutenção, rusqlite 0.31 estava linkando estaticamente um SQLite embutido de dois anos atrás, sem toda essa janela de correções upstream, e thiserror 1 era uma major duplicada já superada em qualquer outro lugar da árvore de dependências.

Por que essa abordagem

Nenhuma dessas precisava de uma decisão de design, só de verificação de que o caminho de atualização era realmente seguro antes de mexer em qualquer coisa. Um bump de versão num driver de banco de dados e numa biblioteca de serialização é exatamente o tipo de mudança que parece trivial e, às vezes, não é.

Implementação

Antes de editar uma linha sequer, rodei um grep em todo ponto de chamada dos três crates pelo codebase: quatro usos de serde_yaml::, umas oito variantes derivadas de thiserror num único enum de erro, e mais de uma dezena de chamadas rusqlite na camada de banco de dados (conexões, transações, prepared statements, a macro params!, variantes de erro específicas). Depois checei cada uso contra o que realmente mudou upstream, não só o número da versão:

• serde_yaml → yaml_serde 0.10.4: confirmado no crates.io como o fork mantido pela organização YAML, com API idêntica ao serde_yaml (from_str/to_string/Value/Error, tudo bate). É uma renomeação de pacote no Cargo, não uma migração de código: serde_yaml = { package = "yaml_serde", version = "0.10" } e todo ponto de chamada serde_yaml:: existente no código-fonte continua compilando sem mudanças.
• rusqlite 0.31 → 0.40.1: nove versões menores, com o SQLite embutido pulando de 3.45.1 para 3.53.2. Puxei as release notes do GitHub de cada versão intermediária e checei cada linha de breaking change contra o que o db.rs do Greenhouse realmente toca. As breaking changes se concentravam em tabelas virtuais, no cache de statements, e em conversões de tipo u64/usize, nada disso usado nesse codebase (timestamps i64 e IDs em string UUID em todo lugar, sem features de vtab/functions/backup/blob).
• thiserror 1 → 2: a própria árvore de dependências do Tauri já estava no thiserror 2 para tudo, exceto o nosso crate. As breaking changes do 2.0 são casos extremos de format string (captura de argumento posicional, ambiguidade de índice de tupla) que não se aplicam a um enum de erro simplesmente derivado.

Pegadinha

Nenhuma, e isso já era a parte interessante. Três dependências, nove versões menores de deriva na pior delas, e o bump em si foi só o cargo build funcionar na primeira tentativa. O trabalho não estava em escrever código, estava em ler changelog o suficiente para saber de antemão que nada quebraria: primeiro faça grep dos pontos de chamada, depois cheque a superfície exata da API que esses pontos tocam contra a lista exata do que mudou, em vez de atualizar a versão e descobrir pelo compilador.

Resultados

Todos os 95 testes passam, incluindo dois que já faziam um round trip completo de serialize-write-read-deserialize pelos mesmos tipos Config que a troca do yaml_serde toca. Cargo build limpo, clippy (deny warnings), e fmt check. O Cargo.lock confirma que o pacote antigo serde_yaml sumiu por completo, e que thiserror 1.0.69/2.0.18 agora coexistem sem problema, já que um punhado de deps transitivas sem relação (bindings GTK/Android puxados pelos backends não-macOS do Tauri) ainda estão fixadas na 1.x.