O versionamento semântico permite 4 componentes nos números de versão?

Todos os exemplos de versões semânticas que eu vi mostram três componentes em uso. Não mais que 2 caracteres de ponto. Na $DAYJOB, usamos 4 componentes em nossos números de versão:

5.0.1.2

O versionamento semântico permite isso?

E como uma questão secundária de nível superior e mais discutível, isso realmente importa? Comecei a pensar que seria uma boa ideia aplicar o controle de versão semântico, mas, no final, entidades como o PCI o substituem.

Eu deveria ter esclarecido meu comentário sobre o PCI. O problema é que as auditorias e seus custos influenciam quando os componentes principais e secundários mudam, não necessariamente um novo recurso verdadeiro. Por exemplo, se um recurso relacionado a pagamentos for introduzido, aumentamos o número menor para PCI. Mas se adicionarmos um novo recurso relacionado a algo na GUI, isso não acontece. Somente o patch muda. Portanto, neste caso, não temos uma opinião sobre o assunto como desenvolvedores, já que alguém toma essas decisões.

versioning semantic-versioning pci

— void.pointer
fonte

O controle de versão semântico é uma diretriz. Onde o PCI declara algo sobre como as coisas devem ser versionadas?

— precisa saber é o seguinte

@ void.pointer você pode dar um exemplo de por que está usando o quarto componente então? Você o está usando para ignorar basicamente as estruturas internas de custos e contabilidade - permitindo que sua equipe rastreie novos recursos sem ultrapassar os números de patch?

— Enderland 1/10

@enderland Sim, basicamente. MAJOR(PCI).MINOR(PCI).FEATURE.HOTFIX+BUILD. Basicamente, temos permissão para alterar o 3º e o 4º componente sem envolver o PCI (e posteriormente os senhores do PCI na empresa). Para mim, parece que isso é um pouco artificial, não tenho certeza se eles são justificados na maneira como gerenciam o número da versão, mas não sei o suficiente sobre o PCI e o processo de auditoria para dizer o contrário.

— precisa saber é o seguinte

Também usamos 4 grupos, e não 3. Por quê? Porque C ++. C ++ tem compatibilidade com versões anteriores binárias e compatibilidade com versões anteriores de origem : a primeira implica a segunda, mas a relação não é simétrica. Portanto, usamos o 4º grupo para compatibilidade binária (você pode corrigir o sistema a quente) e o 3º para compatibilidade de origem (é necessário recompilar, mas não é necessário modificar seu próprio código). E você sabe o que, funciona para nós!

— Matthieu M.

Respostas:

Parece que você está ignorando as convenções normais apenas para evitar despesas gerais / auditorias do processo. Isso ... me parece preocupante.

O que você está fazendo é efetivamente criar um número de versão extra (seu dígito menor do PCI) de maneira intencional, a fim de mover seus números de recurso / versão secundária de volta a um local, para não mais acionar seus critérios de auditoria interna.

De qualquer forma, respondendo à sua pergunta sobre controle de versão semântico, a especificação do controle de versão semântico declara:

Dado um número de versão MAJOR.MINOR.PATCH, aumente o:

Versão MAJOR quando você faz alterações incompatíveis da API,

Versão MENOR quando você adiciona funcionalidade de uma maneira compatível com versões anteriores e

PATCH versão quando você faz correções de erros compatíveis com versões anteriores.

Rótulos adicionais para pré-lançamento e compilação de metadados estão disponíveis como extensões para o formato MAJOR.MINOR.PATCH .

Ênfase minha.

Portanto, a pergunta é: você está usando o quarto caractere para pré-lançamento / compilação de metadados? Ou é basicamente outra indicação de versão que você está lançando?

Se "yes", as especificações do versionamento semântico permitem isso. Se "não", tecnicamente você não está seguindo o controle de versão semântico.

E como uma questão secundária de nível superior e mais discutível, isso realmente importa?

Se você deseja segui-lo rigidamente ou não, é uma decisão que você e sua equipe precisam tomar. O objetivo do controle de versão semântico é ajudar na compatibilidade da API:

As correções de erros que não afetam a API incrementam a versão do patch, as adições / mudanças de API compatíveis com versões anteriores aumentam a versão secundária e as alterações incompatíveis com a API aumentam a versão principal.

Eu chamo esse sistema de "versionamento semântico". Sob esse esquema, os números de versão e a maneira como eles mudam transmitem significado sobre o código subjacente e o que foi modificado de uma versão para a seguinte.

É um sistema que ajuda a tornar mais claro quando o controle de versão afeta os usuários a jusante da API.

Desde que sua API seja igualmente clara, não é um grande negócio o caminho que você escolher. O controle de versão semântico é simples, por exemplo, se eu estiver usando o 3.4.2 e precisar atualizar para o 3.4.10, sei que posso fazê-lo sem quebrar nada. Se a nova versão for 3.5.1, eu sei que é compatível com versões anteriores. E eu sei que a versão 4.0.1 seria uma mudança radical.

Isso faz parte do significado dos números de versão.

@enderland Sim, basicamente. PRINCIPAL (PCI) .MINOR (PCI) .FEATURE.HOTFIX + BUILD. Basicamente, temos permissão para alterar o 3º e o 4º componente sem envolver o PCI (e posteriormente os senhores do PCI na empresa). Para mim, parece que isso é um pouco artificial, não tenho certeza se eles são justificados na maneira como gerenciam o número da versão, mas não sei o suficiente sobre o PCI e o processo de auditoria para dizer o contrário.

Ok, está bem. Você tem um sistema que funciona para você e atende às suas necessidades. Esse é o objetivo do controle de versão.

Se sua API for privada (apenas voltada para o interior), não importa realmente a versão, contanto que faça sentido para você e todos os que a utilizam. Onde a versão em um formato padrão é importante é quando você tem muitos outros consumidores da sua API que precisam saber "o que essa versão significa?"

Ter um sistema de versão arbitrário confundirá as pessoas que estão acostumadas com outros sistemas, como a versão semântica. Mas se ninguém está realmente usando seu sistema de versão, exceto as pessoas que o criaram - isso realmente não importa.

— enderland
fonte

Com relação à sua edição no topo: Deixe-me interpretar o advogado do diabo aqui. As auditorias do PCI custam dinheiro à empresa e nem todos os recursos implementados lhes interessam. Então, por que incorrer em custos e outras despesas gerais apenas com os princípios? Como isso é tão preocupante? Sei que o método para determinar as auditorias provavelmente é defeituoso, mas a separação de preocupações parece razoável. Coisas que não estão remotamente relacionadas ao processamento de cartões são irrelevantes para o PCI.

— precisa saber é o seguinte

@ void.pointer Não estou em posição de julgar por que / como suas auditorias são determinadas. Mas alguém decidiu que queria auditar com base em critérios específicos. Ignorar intencionalmente esse critério de auditoria parece preocupante (independentemente de quanto dinheiro você economiza ao fazer isso).

— Enderland

@ void.pointer, enderland está certo. Se um terrorista ameaça matar sua família se suas versões não forem compostas inteiramente de letras alfabéticas, o verdadeiro problema é o terrorista. Sinta-se à vontade para não seguir o controle de versão semântico para contorná-lo (de fato, eu o sugeriria fortemente neste caso), mas é realmente isso: uma solução alternativa necessária para um problema diferente.

— Paul Draper

@PaulDraper Quando se tornou o único caminho verdadeiro para a versão?

— Andy

@ Andy, não. O OP perguntou sobre o SemVer. IDK porque, mas foi o que ele fez.

— Paul Draper

Na versão atual do Semantic Versioning, que é 2.0.0 , não. Há um requisito que define a versão como o formato XYZ, em que X, Y e Z são números inteiros não negativos que não contêm 0s iniciais:

Um número de versão normal DEVE assumir o formato XYZ, onde X, Y e Z são números inteiros não negativos e NÃO DEVE conter zeros à esquerda. X é a versão principal, Y é a versão secundária e Z é a versão do patch. Cada elemento deve aumentar numericamente. Por exemplo: 1.9.0 -> 1.10.0 -> 1.11.0.

No entanto, a capacidade de adicionar metadados é permitida para:

Os metadados da compilação podem ser indicados anexando um sinal de mais e uma série de identificadores separados por pontos imediatamente após o patch ou a versão de pré-lançamento. Identificadores DEVEM incluir apenas alfanuméricos ASCII e hífen [0-9A-Za-z-]. Identificadores NÃO DEVEM estar vazios. Os metadados da compilação devem ser ignorados ao determinar a precedência da versão. Portanto, duas versões que diferem apenas nos metadados da compilação têm a mesma precedência. Exemplos: 1.0.0-alfa + 001, 1.0.0 + 20130313144700, 1.0.0-beta + exp.sha.5114f85.

Algo importante a ser observado, no entanto, é que o Semantic Versioning é especificamente para software que declara uma API pública:

O software que utiliza versões semânticas DEVE declarar uma API pública. Essa API pode ser declarada no próprio código ou existir estritamente na documentação. Seja como for, deve ser preciso e abrangente.

Isso tende a apoiar o desenvolvimento de bibliotecas ou serviços e não no nível do aplicativo.

O importante a considerar é o significado dos números de versão, tanto para uso interno quanto externo. As versões são apenas identificadores que permitem falar sobre diferenças de software em dois momentos diferentes. O versionamento semântico é um método de estabelecer regras, portanto, se você souber que um aplicativo está usando o versionamento semântico, poderá determinar com mais facilidade o nível de esforço necessário para atualizar seus pacotes. Seguir um padrão comum pode ser bom, mas se você não puder, por qualquer motivo, documentar as regras para seus usuários também deve ser suficiente.

— Thomas Owens
fonte

+1 para a nota pública da API. Não temos uma API pública, mas temos a capacidade de quebrar a compatibilidade com versões anteriores em outros aspectos, como dados. É possível que nós enviamos uma compilação que é instalado em relação às versões antigas, mas os dados não muda, e nós já não são capazes de ler em que os dados (geralmente apoiamos os antigos formatos embora)

— void.pointer