A versão principal rápida é uma evidência de design deficiente?

16

Comecei um trabalho como programador júnior há alguns meses. O sistema em que estamos trabalhando está em produção há ~ 2 anos. Eu não estava envolvido no começo do sistema e no design.

Uma coisa que notei é que a versão principal do sistema já é 11.YZ. De acordo com minha experiência trabalhando com outros sistemas e bibliotecas, não me lembro de ter visto um produto lançando a versão principal tão rapidamente. Existem produtos que existem há anos no 1.XY e ainda recebem recursos e correções.

Supondo que o controle de versão semântico seja usado corretamente, isso indica que o sistema é mal projetado, pois faz grandes alterações de quebra quase a cada quatro meses?

versioning semantic-versioning

— user367035
fonte

2

Essa pergunta dependerá de que essas grandes mudanças causem benefícios (e lucros) suficientes que justifiquem a alta taxa de mudança.

— Rwong 11/03

3

Se esse número de versão usar o Semver e se o sistema tiver uma biblioteca ou outra API da qual outras equipes ou organizações dependem, esse número maior e alto significa que houve problemas para se comprometer com um design de API extensível e estável. Isso também significa que comunicar claramente incompatibilidades é altamente valorizado, o que é uma coisa boa. Para qualquer outra coisa (como nomes de marketing, programas aplicativos, números que não sejam da Semver,…), o número não tem sentido e deve ser amplamente desconsiderado. Basta perguntar aos colegas de trabalho sobre isso, como parte de você conhecer melhor o projeto.

— amon

3

@amon O sistema é usado internamente com clientes móveis públicos que se comunicam com o sistema por meio de API semelhante a REST. O versionamento é Semver, como mencionei, e não a versão de marketing.

— user367035

Número não importa, mas eu ficaria desconfiado se o identificador de versão incluísse algum acrônimo bonito, como Windows NT ou Windows ME ou XP ou realmente qualquer coisa do Windows.

— John Wu

1

@JohnWu: a questão é especificamente sobre o número, por isso, sim, o número não importa. Mais precisamente, é sobre o número no contexto de SemVer, onde o número não só faz matéria, mas também tem um significado precisamente especificada.

— Jörg W Mittag

14

Supondo que o controle de versão semântico seja usado corretamente, isso indica que o sistema é mal projetado, pois faz grandes alterações de quebra quase a cada quatro meses?

Não necessariamente.

Você mencionou nos comentários que esta é uma API interna. Quebrar uma API é ruim, porque você quebra o código de todos. Mas para uma API interna, "todo mundo" é apenas "você", e você é perfeitamente capaz de coordenar essas alterações de API consigo mesmo; portanto, a dor geralmente associada às alterações de API é muito menos pior.

Além disso, a média pode ser maciçamente enganosa: talvez eles tenham 11 alterações na API durante os primeiros dois dias de desenvolvimento inicial e estejam estáveis há 4 anos desde então? O SemVer permite que você faça alterações sem aumentar o número principal, se o número principal for 0, mas não o força . Talvez eles tenham começado a usar o SemVer a partir do dia 0, mesmo durante as fases de prototipagem / exploração?

— Jörg W Mittag
fonte

5

Essa resposta parece abordar diretamente a questão. Algumas das outras respostas seriam válidas se não fosse a suposição do OP de versão semântica.

— joshp

Também digno de nota é que as mudanças não são sempre importantes. Às vezes, eles são realmente muito pequenos (mas importantes). Portanto, eles podem precisar de muito pouca alteração para os usuários. Além disso, pode haver um grau bastante grande de alterações, dependendo de como a API é usada. Às vezes, uma mudança de última hora não afeta todos os usuários, por exemplo. Além disso, as correções de erros podem introduzir alterações significativas, mas é ideal corrigi-las mais cedo ou mais tarde. E se a API for interna, será muito mais fácil lidar com essas pequenas alterações.

— Kat

1

Resposta curta

Não

Resposta longa

"Às vezes, um número é apenas um número"

Esqueça o "versionamento semântico", "racionalidade", "lógica" no mundo louco atual

Por que o Chrome absorve os números de versão tão rapidamente?

os números da "versão" são usados como marcos para os pontos de ramificação, não para os principais lançamentos para impressionar o público da maneira que outros desenvolvedores os usam. E é um fluxo de desenvolvimento contínuo, com recursos prontos ou não, em vez de um evento ocasional que reúne muitos novos recursos para fazer um grande evento

— Lazy Badger
fonte

7

O OP disse que eles estão usando versão semântica; por que você então ignora?

— Jörg W Mittag

-3

Ao usar o controle de versão semântico, ainda há a decisão a ser tomada de quais alterações são consideradas "principais" e quais são "secundárias". Existem vários motivos para aumentar o número da versão - ou para não aumentar.

Sistemas com promessas de compatibilidade com versões anteriores podem acabar aumentando o número da versão principal com a maioria das atualizações, apenas porque há uma quebra de compatibilidade com versões anteriores em alguns casos mais ou menos esotéricos. Os mesmos sistemas podem aderir ao 1.xy quase indefinidamente, porque muito esforço é colocado em compatibilidade com versões anteriores, tentando nunca quebrar nenhum sistema dependente. Ambas as abordagens à numeração de versões podem ser consideradas "conservadoras", mas também podem ser um sinal de um profundo problema subjacente.

Outras vezes, você tem um cronograma de lançamento (pense nos CDs de atualização trimestrais enviados aos clientes) em que faz sentido alterar o número da versão principal, de modo que, em vez de "Versão 3.4 / 16 de outubro", apenas diga "Versão 11.0". Atualmente, mais e mais softwares são lançados em intervalos curtos, tornando os agendamentos de lançamento menos um motivo para seguir um esquema de versão específico. Eu já vi isso em grandes sistemas de armazém que permitem à TI interna apenas um dia de inatividade por trimestre (geralmente um domingo). Este dia é o dia da implantação e é marcado com uma nova versão principal sempre.

Alguns programas têm dependências externas de extrema importância, porque o usuário precisará atualizar as duas ao mesmo tempo. Se você possui um complemento do Word que funciona apenas com o Word 2010 e outro no Word 2013, convém sincronizar seus números de versão principais com os do MS-Word. Aqui, os números principais são muito importantes, porque alguns de seus usuários estarão "atrasados" em sua programação normal de atualizações, pois não foram atualizados para a versão mais atual do Word (ou qualquer outra coisa em que você confie: SAP, Dynamics, etc).

Às vezes, outros fatores externos determinam os números de versão. Se você possui um software fiscal, pode haver atualizações anuais correspondentes à lei tributária (que tende a entrar em vigor em 1º de janeiro). Esses sistemas terão as principais versões alteradas exatamente uma vez por ano - não porque esse é o cronograma de atualização, mas porque isso é de outra importância para o cliente: se você fizer seus impostos de 2016, é melhor ter um programa atualizado para a legislação tributária de 2016.

No final, os números de versão dependem de tantos fatores - geralmente específicos de um domínio - que o número por si só não informa nada sobre o estado da sua base de código. É uma abordagem muito melhor para analisar quando, por que e como as implantações acontecem - e com que suavidade isso ocorre. Se você pode lançar uma atualização importante para 10.000 clientes e fazer algumas ligações telefônicas - provavelmente está bem. Se você lançar um patch menor para 10 clientes e precisar fazer horas extras por causa disso, provavelmente algo está errado.

— Hazzit
fonte

3

"Ao usar o controle de versão semântico, ainda há a decisão a ser tomada de quais alterações são consideradas" principais "e quais são" secundárias "." - Não, não há; isso é definido com precisão na especificação. "Existem várias razões para aumentar o número da versão - ou para não aumentar." - Não, não há; há precisamente uma razão para aumentar o número principal (sobre o qual esta questão se refere), e ela é definida precisamente na especificação.

— Jörg W Mittag

1

@ JörgWMittag Ou eu estou lendo errado, ou a especificação diz especificamente quando você DEVE aumentar os números de versão, mas não diz nada sobre quando você PODE.

— Hazzit

-4

O consenso sobre o significado dos números de versão é de fato major.minor.revision.buildnumber

Se o major subir rapidamente, pode ser que o desenvolvedor tenha todas essas novas idéias e trabalhe muito.

No mundo dos negócios, no entanto, pode haver outros motivos para aumentar o número da versão principal. Gostar

As vendas caíram, os clientes / usuários aguardam o próximo grande lançamento antes de atualizar.
O contrato diz que os clientes têm direito a pequenas atualizações. O fornecedor não pode cobrá-los por isso, uma pequena melhoria é vendida como uma grande atualização do produto.
O concorrente X está no jogo há mais tempo, portanto, o número da versão principal é maior que o seu. Isso faz com que pareça que você está atrasado, você precisa "acompanhar".

— Martin Maat
fonte

6

A pergunta é marcada com versão semântica , o OP menciona versão semântica na pergunta e reafirmou nos comentários que eles estão usando versão semântica. A especificação SemVer diz claramente quando as versões principais são incrementadas. Nenhum dos seus "outros motivos" se aplica.

— Jörg W Mittag