Executando verificação de segurança...
5

Como funcionam os números de versão nos aplicativos publicados? Existe uma regra para o formato?

Estou com uma dúvida sobre os números de versão exibidos nos aplicativos profissionais.

Alguns apps usam versões simples como 1.0.0(1), enquanto outros mostram algo mais complexo como 12.345.67890123(1234567891829283).

No caso do aplicativo "Meu Alelo" tem esse formato mais extenso, atualmente a versão deles é 8.5.0(2025051505)(2025051505) enquanto que o App "Gov" está na versão 3.7.2(191)

Minha dúvida é:

  • Como definir um padrão?

Eu cheguei a encontrar o site de versionamento semântico, mas ainda preciso de ajuda para definir padrões.

https://semver.org/lang/pt-BR/

Carregando publicação patrocinada...
4

Dê uma pesquisada sobre SemVer https://semver.org/lang/pt-BR/

Mas, basicamente o primeiro número é chamado major, que é a versão "maior" do app. Ele é incrementado quando a versão atual fica incompatível com a anterior.
A do meio são as features. Sempre que vc adiciona algo que é considerado algo a mais, vc o incrementa e zera o último.
O último é o fix. A cada correção ou ajuste que você faz, você incrementa ele.
Aquele número entre parêntese no Gov, provavelmente é o número do build. A play store mantém esse número sequencial com as versões enviadas.

Mas enfim, isso que eu falei é apenas o resumo. Leia o conteúdo do semver para saber mais.

2

Normalmente vejo os padrões do SemVer usados para projetos que serão usados como dependências de outros projetos, como libs e frameworks.

Para aplicações cada empresa usa uma forma diferente que faz sentido apenas para a equipe, como numeração sequencial do build, data do build no formato AAAAMMDD (20250610) para manter um valor ordenável, e outras combinações.

Há também empresas que mantém dois tipos de números de versão, um "comercial" que será visto pelos usuários e outro de "produto" que é mais entendido pela equipe de desenvolvimento. Por exemplo, um app na versão comercial 2.3 e na versão de produto 2.3.88799.345.01.


Resumindo, se estiver criando uma biblioteca, ferramenta, framework... tente se manter nos padrões do SemVer.

Se for uma aplicação, use algo que faça sentido para sua empresa e clientes, nada impede de ser o SemVer também.

1
1

Eu uso a versão parecida com o q é utilizado no mundo do flutter, algo como 1.2.3+4. O klawdyo explicou legal sobre o q significa.

Mas o que queria recomendar é q evite data na versão do build se não houver um bom motivo para usar data. Pelo menos para mim, já teve situações q precisei fazer build 2 vezes no msm dia. Não lembro no iOS, mas pelo menos no android, o build é sempre incremental. Vc pode aumentar de 1 em 1, pode pular para cima qntos números quiser, mas vc nunca pode repetir o msm número ou voltar o número depois que ele foi enviado para a play store console.

Por exemplo, teve um dia q eu enviei com a data 1.2.3+20250610 e deu erro nos testes bem antes de mandar para o público. Ai tive q corrigir o problema e como ele não aceita msm número do build, precisei gerar com 1.2.3+20250611, onde acaba sendo uma gambiarra já q o "dia" estou utilizando é o dia seguinte e não o dia em q estou enviando. Ou seja, vc acabará bagunçando os números semanticamente. Por sorte esse app já não tem mais tanta atualização, ou seja, não tenho tantos problemas de conflitos. E tbm melhorei meu CI/CD para evitar q o build vá com erros para a play store console. Msm assim não uso mais por causa desse problemas, então eu apenas incremento +1 no nro do build q dá na msm.

Edit: ah, só complementando, eu só estou comentando sobre o nro do build baseado na minha experiência q aconteceu com deploy na play store console. Não acho q isso possa acontecer com vc, pois imagino q a parte web é bem mais tranquila em relação a isso. Mas se tiver, já sabe q não pode repetir o nro do build, msm q vc mude a versão e mantenha o nro do build. Por exemplo, se antes era 1.2.3+20250610 e vc colocar 1.2.4+20250610, na play store console irá reclamar do msm jeito, pois ele considera o nro do build e não a versão. Regrinhas chatas q eles definiram q me fez evitar datas nos builds em qqr projeto.