Nesse caso, precisamos entender melhor o que você e sua equipe estão discutindo.
O que vocês estão discutindo? Vocês estão discutindo a atualização do ACBr ou o "deploy", que é o envido de versões aos clientes?
Vocês precisam de uma estratégia de "desenvolvimento" e uma estratégia de deploy. Tudo bem que as duas estratégias podem ser interligadas, como é o caso quando se usa um sistema de "Implantação Contínua". Mas são duas coisas bem diferentes.
Não vou dizer que você está errado nas sua posição. Porque não está. Na verdade, talvez não tenha certo ou errado aqui. E claro, ninguém deveria ficar desesperado para instalar uma nova versão sem fazer testes. Também, antes de enviar uma versão aos clientes é preciso levar em conta a quantidade de clientes, o tamanho da equipe de desenvolvimento e suporte e até o plano de negócios da empresa.
Por outro lado, acho que as seguintes perguntas precisam também ser analisadas: Só se envia uma nova versão ao cliente para resolver problemas? Não são apresentadas ao cliente os novos recursos como algo que facilita a vida dele? Não seria muito mais interessante comercialmente se o programa tivesse sempre novidades para cativar o usuário? Não será muito mais difícil encontrar e resolver um problema se de uma versão para outra houverem muitas alterações no código? Que controle se faz de versão do software que está instalado no cliente? Consegue-se facilmente reproduzir no ambiente de desenvolvimento?
Vou deixar esse link de artigo aqui que eu achei muito interessante de um pessoal que saiu do "GitFlow" e foi pro "Trunk Based Development". Leia também os comentários onde alguns categoricamente não concordam. É um artigo pra pensar no desenvolvimento.
https://www.gamasutra.com/blogs/NiklasGray/20170927/306445/Moving_away_from_GitFlow.php
Enfim, eu disse implicitamente antes, mas agora vou falar explicitamente.
Não estou dizendo que uma maneira é melhor do que a outra. Cada empresa precisa pesar as vantagens e desvantagens e decidir o que é melhor para empresa, sua equipe e seus clientes. Não leve em conta só a sua equipe. Mas também, não leve em conta só os clientes. Isso poderia fazer sua equipe sofrer.