Eu interpreto essa situação como tendo dois problemas básicos, possivelmente três.
- Um upgrade de SDK indesejado chegou à origem, onde poderia afetar negativamente o produto.
- Da pergunta: o colaborador que realizou o upgrade indesejado não sabia sobre uma decisão específica anterior de não fazer upgrade.
O primeiro deles, na minha opinião, é o mais sério. Se uma atualização indesejada do SDK puder ser incluída no código, outros problemas também podem ocorrer.
Alguém sugeriu adicionar um caso de teste de unidade que falhará se detectar a atualização. Embora isso impeça a atualização, creio que esse é um caminho perigoso, levando a fluxo de lava Tempo. Parece inevitável que, em algum momento no futuro, o SDK será atualizado, para trazer novos recursos ou correções de bugs, ou porque a versão antiga não é mais suportada. Imagine os arranhões na cabeça, talvez até os argumentos, que ocorrerão quando esse teste de unidade falhar.
Acho que a solução mais geral é ajustar o processo de desenvolvimento. Para git, use o processo de solicitação de pull . Para ferramentas do Subversion e mais antigas, use ramificações e diff. Mas tem algum processo que permite aos desenvolvedores seniores pegar esses tipos de problemas antes eles entrarem na base de código e afetar outros desenvolvedores.
Se o processo de solicitação pull tiver sido usado em sua situação e se cada solicitação de recebimento for restrita e específica, pouco tempo teria sido desperdiçado. Um pedido de pull para atualizar o SDK teria sido enviado e recusou com comentários que a atualização não é desejada. Ninguém mais teria sido afetado e não haveria necessidade de reverter a atualização do SDK.
Mas para responder diretamente a pergunta original, eu concordo com outros que esperar que todos os desenvolvedores leiam completamente o histórico de revisão do código, notas de versão, etc. para avisos como este é um desperdício de tempo valioso. O que há de errado com um e-mail curto da equipe?
Possível terceira questão: por que a atualização não é desejada em primeiro lugar? Claramente, pelo menos, um desenvolvedor pensou que a atualização seria uma coisa boa. Há muitas boas razões para atrasar uma atualização, mas também muitas más. Tome cuidado para evitar o fluxo de lava (código desnecessário de compatibilidade retroativa) e cult de carga ("não podemos atualizar isso, mas eu não sei porque ") antipadrões!