Controle de versão de software - Software versioning

O controle de versão de software é o processo de atribuição de nomes de versão exclusivos ou números de versão exclusivos a estados exclusivos de software de computador. Dentro de uma determinada categoria de número de versão (principal, secundária), esses números são geralmente atribuídos em ordem crescente e correspondem a novos desenvolvimentos no software. Em um nível mais refinado, o controle de revisão é freqüentemente usado para rastrear versões incrementalmente diferentes de informações, sejam essas informações ou não um software de computador.

O software de computador moderno é frequentemente rastreado usando dois esquemas de versão de software diferentes: número de versão interna que pode ser incrementado muitas vezes em um único dia, como um número de controle de revisão, e uma versão de lançamento que normalmente muda com muito menos frequência, como versão semântica ou um nome de código do projeto .

Esquemas

Uma variedade de esquemas de numeração de versão foi criada para controlar as diferentes versões de um software. A onipresença dos computadores também fez com que esses esquemas fossem usados ​​em contextos fora da computação.

Identificadores baseados em sequência

Sequência do número da versão

Em esquemas de versão de software baseados em sequência, cada versão de software recebe um identificador exclusivo que consiste em uma ou mais sequências de números ou letras. Esta é a extensão da comunalidade; esquemas variam amplamente em áreas como a quantidade de sequências, a atribuição de significado a sequências individuais e os meios de incrementar as sequências.

Mudança de significância

Em alguns esquemas, identificadores baseados em sequência são usados ​​para transmitir a importância das mudanças entre as versões. As mudanças são classificadas por nível de significância, e a decisão de qual sequência alterar entre as versões é baseada na significância das mudanças da versão anterior, em que a primeira sequência é alterada para as mudanças mais significativas e as mudanças nas sequências após a primeira representam mudanças de significância decrescente.

Dependendo do esquema, a significância pode ser avaliada por linhas de código alteradas, pontos de função adicionados ou removidos, impacto potencial sobre os clientes em termos de trabalho necessário para adotar uma nova versão, risco de bugs ou alterações de quebra não declaradas, grau de mudanças no layout visual , quantidade de novos recursos ou quase qualquer coisa que os desenvolvedores de produto ou profissionais de marketing considerem significativo, incluindo o desejo de marketing de enfatizar a "bondade relativa" da nova versão.

O controle de versão semântica (também conhecido como SemVer) é um esquema de versão amplamente adotado que usa uma sequência de três dígitos (Major.Minor.Patch), uma tag de pré-lançamento opcional e uma meta tag de construção opcional. Neste esquema, risco e funcionalidade são as medidas de significância. As alterações de interrupção são indicadas aumentando o número principal (alto risco), os novos recursos não interruptivos aumentam o número menor (risco médio) e todas as outras alterações não interruptivas aumentam o número do patch (risco mais baixo). A presença de uma etiqueta de pré-lançamento (-alfa, -beta) indica risco substancial, assim como um grande número de zero (0.yz), que é usado para indicar um trabalho em andamento que pode conter qualquer nível de potencialmente quebra de mudanças (maior risco).

Os desenvolvedores podem optar por pular várias versões secundárias de uma vez para indicar que recursos significativos foram adicionados, mas não são suficientes para garantir o incremento de um número de versão principal; por exemplo, Internet Explorer 5 de 5.1 a 5.5 ou Adobe Photoshop 5 a 5.5. Isso pode ser feito para enfatizar o valor da atualização para o usuário do software, ou, como no caso da Adobe, para representar um lançamento no meio do caminho entre as versões principais (embora os níveis de versionamento baseado em sequência não sejam necessariamente limitados a um único dígito, como no Blender versão 2.91 ou Minecraft Java Edition após 1.10).

Uma abordagem diferente é usar os números maiores e menores , junto com uma string alfanumérica denotando o tipo de lançamento, por exemplo, "alfa" (a), "beta" (b) ou "candidato a lançamento" (rc). Um trem de lançamento de software usando esta abordagem pode ser semelhante a 0,5, 0,6, 0,7, 0,8, 0,9 → 1,0b1, 1,0b2 (com algumas correções), 1.0b3 (com mais correções) → 1.0rc1 (que, se for estável o suficiente ) , 1.0rc2 (se mais bugs forem encontrados) → 1.0. É uma prática comum neste esquema bloquear novos recursos e alterações importantes durante as fases de candidato a lançamento e, para algumas equipes, até mesmo os betas são bloqueados apenas para correções de bugs, para garantir a convergência no lançamento de destino.

Outros esquemas conferem significado às sequências individuais:

major.minor [.build [.revision]] (exemplo: 1.2.12.102 )
major.minor [.maintenance [.build]] (exemplo: 1.4.3.5249 )

Novamente, nesses exemplos, a definição do que constitui uma mudança "principal" em oposição a uma "menor" é inteiramente subjetiva e depende do autor, como é o que define uma "construção", ou como uma "revisão" difere de uma "Pequena alteração.

Bibliotecas compartilhadas no Solaris e Linux podem usar o formato current.revision.age onde:

current : O número de interface mais recente que a biblioteca implementa.
revisão : O número de implementação da interface atual.
idade : A diferença entre as interfaces mais recentes e mais antigas que a biblioteca implementa. Este uso do terceiro campo é específico para libtool : outros podem usar um significado diferente ou simplesmente ignorá-lo.

Um problema semelhante de significância de mudança relativa e nomenclatura de versão existe na publicação de livros, onde os números ou nomes das edições podem ser escolhidos com base em vários critérios.

Na maioria dos softwares proprietários, a primeira versão lançada de um produto de software tem a versão 1.

Grau de compatibilidade
Número da versão de três partes do versionamento semântico

Alguns projetos usam o número da versão principal para indicar versões incompatíveis. Dois exemplos são o Apache Portable Runtime (APR) e o FarCry CMS.

O controle de versão semântica é uma convenção formal para especificar a compatibilidade usando um número de versão de três partes: versão principal; versão secundária; e patch. O número do patch é incrementado para pequenas alterações e correções de bugs que não alteram a interface de programação de aplicativo (API) do software . A versão secundária é incrementada para lançamentos que adicionam recursos de API novos, mas compatíveis com versões anteriores, e a versão principal é incrementada para alterações de API que não são compatíveis com versões anteriores. Por exemplo, o software que depende da versão 2.1.5 de uma API é compatível com a versão 2.2.3, mas não necessariamente com 3.2.4.

Freqüentemente, os programadores escrevem um novo software para ser compatível com versões anteriores , ou seja, o novo software é projetado para interagir corretamente com as versões mais antigas do software (usando protocolos e formatos de arquivo antigos) e a versão mais recente (usando os protocolos e formatos de arquivo mais recentes). Por exemplo, o IBM z / OS foi projetado para funcionar corretamente com 3 versões principais consecutivas do sistema operacional em execução no mesmo sysplex. Isso permite que as pessoas que executam um cluster de computador de alta disponibilidade mantenham a maioria dos computadores funcionando enquanto uma máquina por vez é desligada, atualizada e restaurada para o serviço.

Freqüentemente, os cabeçalhos dos pacotes e o formato do arquivo incluem um número de versão - às vezes o mesmo que o número da versão do software que o escreveu; outras vezes, um "número de versão do protocolo" independente do número da versão do software. O código para lidar com protocolos e formatos de arquivo obsoletos costuma ser visto como lixo .

Designando estágio de desenvolvimento

O software no estágio experimental ( alfa ou beta ) geralmente usa um zero na primeira posição ("principal") da sequência para designar seu status. No entanto, esse esquema é útil apenas para os estágios iniciais, não para versões futuras com software estabelecido onde o número da versão já passou de 0.

Vários esquemas são usados ​​para denotar o status de uma versão mais recente:

  • O sufixo alfanumérico é um esquema comum adotado por versões semânticas. Neste esquema, as versões são afixadas com um travessão mais alguns caracteres alfanuméricos para indicar o status.
  • O status numérico é um esquema que usa números para indicar o status como se fizesse parte da sequência. Uma escolha típica é a terceira posição para o versionamento de quatro posições.
  • Numérico 90+ é outro esquema que usa números, mas aparentemente em um número de uma versão anterior. Um grande número na última posição, normalmente 90 ou mais, é usado. Isso é comumente usado por projetos de código aberto mais antigos, como Fontconfig .
Comparação de indicadores de estágio de desenvolvimento
Estágio Semver Num. Status Num 90+
Alfa 1.2.0-a.1 1.2.0.1 1.1.90
Beta 1.2.0-b.2 1.2.1.2 1.1.93
Candidato à liberação 1.2.0-rc.3 1.2.2.3 1.1.97
Liberar 1.2.0 1.2.3.0 1.2.0
Correções pós-lançamento 1.2.5 1.2.3.5 1.2.5

As duas formas puramente numéricas removem a lógica especial necessária para lidar com a comparação de "alpha <beta <rc <no prefix" conforme encontrado no versionamento semântico, ao custo da clareza. (o versionamento semântico, na verdade, não especifica termos específicos para os estágios de desenvolvimento; a comparação é simplesmente em ordem lexicográfica .)

Sequências de incremento

Existem duas escolas de pensamento sobre como os números das versões numéricas são incrementados. A maioria dos pacotes de software livre e de código aberto , incluindo MediaWiki , trata as versões como uma série de números individuais, separados por pontos, com uma progressão como 1.7.0, 1.8.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0, 1.11.1, 1.11.2 e assim por diante.

Por outro lado, alguns pacotes de software identificam as versões por números decimais: 1,7, 1,8, 1,81, 1,82, 1,9, etc. As versões decimais eram comuns na década de 1980, por exemplo, com NetWare , DOS e Microsoft Windows , mas mesmo nos anos 2000 foram usados, por exemplo, pelo Opera e pelo Movable Type . No esquema decimal, 1.81 é a versão secundária após 1.8, enquanto as versões de manutenção (ou seja, somente correções de bugs) podem ser denotadas com um sufixo alfabético, como 1.81a ou 1.81b.

O esquema de numeração de versão GNU padrão é major.minor.revision, mas o Emacs é um exemplo notável usando outro esquema onde o número principal (1) foi eliminado e uma revisão do site do usuário foi adicionada, que é sempre zero nos pacotes originais do Emacs, mas aumentada pelos distribuidores . Da mesma forma, os números dos pacotes Debian são prefixados com uma "época" opcional, que é usada para permitir que o esquema de versão seja alterado.

Reinicializando

Em alguns casos, os desenvolvedores podem decidir redefinir o número da versão principal. Isso às vezes é usado para denotar uma nova fase de desenvolvimento sendo lançada. Por exemplo, o Minecraft Alpha foi executado da versão 1.0.0 à 1.2.6 e, quando o Beta foi lançado, ele redefiniu o número da versão principal e passou de 1.0 para 1.8. Depois que o jogo foi totalmente lançado, o número da versão principal novamente foi redefinido para 1.0.0.

Separando sequências

Quando impressas, as sequências podem ser separadas por caracteres. A escolha dos personagens e seu uso varia de acordo com o esquema. A lista a seguir mostra exemplos hipotéticos de esquemas de separação para a mesma versão (a revisão do décimo terceiro nível para a revisão do quarto nível para a segunda revisão do primeiro nível):

  • Um esquema pode usar o mesmo caractere entre todas as sequências: 2.4.13, 2/4/13, 2-4-13
  • Uma escolha de esquema de quais sequências separar pode ser inconsistente, separando algumas sequências, mas não outras: 2.413
  • A escolha de caracteres de um esquema pode ser inconsistente dentro do mesmo identificador: 2.4_13

Quando um ponto é usado para separar sequências, ele pode ou não representar um ponto decimal, - consulte a seção “ Sequências incrementais ” para vários estilos de interpretação.

Número de sequências

Às vezes, há um quarto número não publicado que indica a construção do software (conforme usado pela Microsoft ). Adobe Flash é um caso notável em que um número de versão de quatro partes é indicado publicamente, como em 10.1.53.64. Algumas empresas também incluem a data de construção. Os números da versão também podem incluir letras e outros caracteres, como Lotus 1-2-3 Release 1a.

Usando número negativo

Alguns projetos usam números de versão negativos. Um exemplo é o compilador SmartEiffel que começou de -1,0 e foi contado de forma ascendente até 0,0.

Data de lançamento

Tela inicial do Street Fighter EX mostrando o número do lançamento no formato CalVer

Muitos projetos usam um esquema de controle de versão baseado em data chamado Calendar Versioning (também conhecido como CalVer ).

Ubuntu Linux é um exemplo de projeto que usa controle de versão de calendário; O Ubuntu 18.04, por exemplo, foi lançado em abril de 2018. Ele tem a vantagem de ser facilmente identificável com cronogramas de desenvolvimento e cronogramas de suporte. Alguns videogames também usam data como versionamento, por exemplo, o jogo de arcade Street Fighter EX . Na inicialização, ele exibe o número da versão como uma data mais um código de região, por exemplo 961219 ASIA .

Ao usar datas no controle de versão, por exemplo, nomes de arquivo, é comum usar o esquema ISO 8601 : AAAA-MM-DD, pois isso é facilmente classificado em seqüência de caracteres em ordem crescente ou decrescente. Os hífens às vezes são omitidos. O Wine projeto anteriormente utilizada uma data de versão de esquema, que usou o ano seguido do mês seguido pelo dia da libertação; por exemplo, "Wine 20040505".

Os números de compilação do Microsoft Office são uma data codificada: os primeiros dois dígitos indicam o número de meses que se passaram desde janeiro do ano em que o projeto começou (com cada versão principal do Office sendo um projeto diferente), enquanto os dois últimos dígitos indicam o dia desse mês. Portanto, 3419 é o 19º dia do 34º mês após o mês de janeiro do ano em que o projeto foi iniciado.

Outros exemplos que identificam versões por ano incluem Adobe Illustrator 88 e WordPerfect Office 2003. Quando um ano é usado para denotar a versão, geralmente é para fins de marketing e também existe um número de versão real. Por exemplo, o Microsoft Windows 95 tem versão interna como MS-DOS 7.00 e Windows 4.00; da mesma forma, o Microsoft Windows 2000 Server tem a versão interna do Windows NT 5.0 ("NT" sendo uma referência ao nome do produto original).

Pitão

A Python Software Foundation publicou PEP 440 - Identificação de Versão e Especificação de Dependência, delineando seu próprio esquema flexível, que define um segmento de época, um segmento de lançamento, segmentos de pré-lançamento e pós-lançamento e um segmento de lançamento de desenvolvimento.

TeX

TeX tem um sistema de numeração de versão idiossincrático . Desde a versão 3, as atualizações foram indicadas pela adição de um dígito extra no final, de modo que o número da versão assintoticamente se aproxime de π ; uma forma de numeração unária - o número da versão é o número de dígitos. A versão atual é 3.14159265. Isso é um reflexo do TeX ser muito estável, e apenas pequenas atualizações são antecipadas. O desenvolvedor do TeX, Donald Knuth , afirmou que a "mudança absolutamente final (a ser feita após [sua] morte)" será mudar o número da versão para π , ponto em que todos os bugs restantes se tornarão recursos permanentes.

De forma semelhante, o número da versão do Metafont assintoticamente se aproxima de e .

maçã

Durante a era do Mac OS clássico , os números das versões secundárias raramente iam além de ".1". Quando o faziam, geralmente saltavam direto para ".5", sugerindo que o lançamento era "mais significativo". Assim, "8.5" foi comercializado como seu próprio lançamento, representando "Mac OS 8 e meio", e 8.6 significava efetivamente "8.5.1".

O Mac OS X se afastou dessa tendência, em grande parte porque "X" (o numeral romano para 10) estava no nome do produto. Como resultado, todas as versões do OS X começaram com o número 10. A primeira versão principal do OS X recebeu o número de versão 10.0, mas a próxima versão principal não foi a 11.0. Em vez disso, ele foi numerado como 10.1, seguido por 10.2, 10.3 e assim por diante para cada versão principal subsequente. Portanto, a 11ª versão principal do OS X foi rotulada como "10.10". Embora o "X" tenha sido retirado do nome no macOS 10.12 , esse esquema de numeração continuou no macOS 10.15. No esquema de versão baseado em "X", o terceiro número (em vez do segundo) denotava uma versão secundária e atualizações adicionais abaixo deste nível, bem como atualizações para uma determinada versão principal do OS X após o lançamento de um novo versão principal, foram intituladas Atualizações Suplementares.

O numeral romano X foi aproveitado simultaneamente para fins de marketing em várias linhas de produtos. Tanto o QuickTime quanto o Final Cut Pro saltaram da versão 7 diretamente para a versão 10, QuickTime X e Final Cut Pro X. Como o próprio Mac OS X, os produtos não eram atualizações para versões anteriores, mas programas totalmente novos. Tal como acontece com o OS X, as versões principais desses programas aumentaram o segundo dígito e as versões secundárias foram denotadas com um terceiro dígito. O "X" foi retirado do nome do Final Cut com o lançamento do macOS 11.0 (veja abaixo), e a marca do QuickTime tornou-se discutível quando o framework foi preterido em favor do AVFoundation em 2011 (o programa para reproduzir vídeo QuickTime foi nomeado apenas QuickTime Player de o começo).

O próximo lançamento do macOS da Apple, provisoriamente numerado como 10.16, foi oficialmente anunciado como macOS 11.0 na WWDC em junho de 2020. A versão seguinte do macOS, macOS Monterey, foi lançada na WWDC 2021 e aumentou seu número de versão principal para 12.

Microsoft Windows

O sistema operacional Microsoft Windows foi inicialmente rotulado com números de versão padrão do Windows 1.0 até o Windows 3.11 . Depois disso, a Microsoft excluiu o número da versão do nome do produto. Para Windows 95 (versão 4.0), Windows 98 (4.10) e Windows 2000 (5.0), o ano do lançamento foi incluído no título do produto. Depois do Windows 2000, a Microsoft criou a família do Windows Server que continuou o estilo baseado em ano com uma diferença: para versões menores, a Microsoft colocou o sufixo "R2" no título, por exemplo, Windows Server 2008 R2 (versão 6.1). Este estilo permaneceu consistente até esta data. As versões cliente do Windows, entretanto, não adotaram um estilo consistente. Primeiro, eles receberam nomes com sufixos alfanuméricos arbitrários, como no Windows ME (4.90), no Windows XP (5.1) e no Windows Vista (6.0). Então, mais uma vez a Microsoft adotou números incrementais no título, mas desta vez, eles não eram números de versão; os números da versão do Windows 7 , Windows 8 e Windows 8.1 são, respectivamente, 6.1, 6.2 e 6.3. No Windows 10 , o número da versão saltou para 10.0 e as atualizações subsequentes para o sistema operacional apenas aumentaram o número da compilação e o número da revisão da compilação de atualização (UBR).

O sucessor do Windows 10, o Windows 11 , foi lançado em 15 de outubro de 2021. Apesar de ser chamado de "11", o novo lançamento do Windows não aumentou seu número de versão principal para 11. Em vez disso, manteve o mesmo número de versão 10.0 , usado pelo Windows 10.

Outros esquemas

Alguns produtores de software usam esquemas diferentes para denotar versões de seu software. O projeto Debian usa um esquema de versão principal / secundária para lançamentos de seu sistema operacional, mas usa nomes de código do filme Toy Story durante o desenvolvimento para se referir a versões estáveis, instáveis ​​e de teste.

BLAG Linux e GNU apresentam números de versão muito grandes: os lançamentos principais têm números como 50000 e 60000, enquanto os lançamentos menores aumentam o número em 1 (por exemplo, 50001, 50002). As versões alfa e beta recebem números de versão decimais ligeiramente menores do que o número da versão principal, como 19999.00071 para alfa 1 da versão 20000 e 29999,50000 para beta 2 da versão 30000. A partir de 9001 em 2003, a versão mais recente em 2011 é 140000.

O Urbit usa versionamento Kelvin (nomeado após a escala de temperatura Kelvin absoluta ): as versões do software começam em um número alto e contam até a versão 0, ponto em que o software é considerado concluído e nenhuma modificação adicional é feita.

Números de versão interna

O software pode ter um número de versão "interno" que difere do número da versão mostrado no nome do produto (e que normalmente segue as regras de numeração de versão de forma mais consistente). Java SE 5.0, por exemplo, tem o número da versão interna 1.5.0 e as versões do Windows a partir do NT 4 continuaram com as versões numéricas padrão internamente: Windows 2000 é NT 5.0, XP é Windows NT 5.1, Windows Server 2003 e Windows XP Professional x64 Edition são NT 5.2, Windows Server 2008 e Vista são NT 6.0, Windows Server 2008 R2 e Windows 7 são NT 6.1, Windows Server 2012 e Windows 8 são NT 6.2 e Windows Server 2012 R2 e Windows 8.1 são NT 6.3, no entanto, a primeira versão do Windows 10 era 10.0 (10.0.10240). Observe, entretanto, que o Windows NT está apenas em sua quinta revisão principal, já que sua primeira versão foi numerada como 3.1 (para coincidir com o número da versão atual do Windows) e o lançamento do Windows 10 deu um salto de versão de 6,3 para 10,0.

Versões de pré-lançamento

Em conjunto com os vários esquemas de controle de versão listados acima, um sistema para denotar versões de pré-lançamento é geralmente usado, conforme o programa avança pelos estágios do ciclo de vida de lançamento do software .

Os programas que estão em um estágio inicial são freqüentemente chamados de software "alfa", após a primeira letra do alfabeto grego. Depois de amadurecerem, mas ainda não estarem prontos para lançamento, eles podem ser chamados de software "beta", após a segunda letra do alfabeto grego. Geralmente, o software alfa é testado apenas por desenvolvedores, enquanto o software beta é distribuído para testes da comunidade.

Alguns sistemas usam versões numéricas menores que 1 (como 0,9), para sugerir sua abordagem para uma versão final "1.0". Esta é uma convenção comum em software de código aberto . No entanto, se a versão de pré-lançamento for para um pacote de software existente (por exemplo, versão 2.5), um "a" ou "alfa" pode ser anexado ao número da versão. Portanto, a versão alfa do lançamento 2.5 pode ser identificada como 2.5a ou 2.5.a.

Uma alternativa é referir-se às versões de pré-lançamento como "candidatos a lançamento", de modo que os pacotes de software que serão lançados em breve como uma versão específica possam ter essa marca de versão seguida por "rc- #", indicando o número do candidato a lançamento ; quando a versão final é lançada, a tag "rc" é removida.

Trem de liberação

Um trem de lançamento de software é uma forma de programação de lançamento de software em que várias séries distintas de versões de software para vários produtos são lançadas como vários "trens" diferentes em uma programação regular. Geralmente, para cada linha de produto, vários trens de liberação diferentes estão operando em um determinado momento, com cada trem movendo-se da liberação inicial para o vencimento final e aposentadoria em uma programação planejada. Os usuários podem experimentar um trem de lançamento mais recente antes de adotá-lo para produção, permitindo-lhes experimentar lançamentos mais novos, "brutos" mais cedo, enquanto continuam a seguir os lançamentos pontuais do trem anterior para seus sistemas de produção antes de passar para o novo trem de lançamento como torna-se maduro.

A plataforma de software IOS da Cisco usou uma programação de trem de lançamento com muitos trens distintos por muitos anos. Mais recentemente, várias outras plataformas, incluindo Firefox e Fenix ​​para Android, Eclipse , LibreOffice , Ubuntu , Fedora, Python, digiKam e VMware adotaram o modelo de trem de lançamento.

Modificações no sistema numérico

Versões ímpares para lançamentos de desenvolvimento

Entre as séries 1.0 e 2.6.x, o kernel do Linux usava números de versão menores ímpares para denotar lançamentos de desenvolvimento e até números de versão menores para denotar lançamentos estáveis; consulte o kernel do Linux § Numeração da versão . Por exemplo, o Linux 2.3 foi uma família de desenvolvimento do segundo maior design do kernel do Linux, e o Linux 2.4 foi a família de versões estáveis ​​em que o Linux 2.3 amadureceu. Após o número da versão secundária no kernel do Linux, está o número da versão, em ordem crescente; por exemplo, Linux 2.4.0 → Linux 2.4.22. Desde o lançamento de 2004 do kernel 2.6, o Linux não usa mais este sistema e tem um ciclo de lançamento muito mais curto.

O mesmo sistema ímpar-par é usado por algum outro software com longos ciclos de lançamento, como Node.js até a versão 0.12, bem como GNOME e WineHQ .

Significado político e cultural dos números de versão

Versão 1.0 como um marco

As comunidades de software livre e de código aberto tendem a lançar software cedo e frequentemente . As versões iniciais são números menores que 1, com essa versão 0.x usada para transmitir que o software está incompleto e não é confiável o suficiente para lançamento geral ou utilizável em seu estado atual. Alterações incompatíveis com versões anteriores são comuns com versões 0.x. A versão 1.0 é usada como um marco principal , indicando que o software tem pelo menos todos os recursos principais mais as funções que os desenvolvedores queriam obter nessa versão e é considerado confiável o suficiente para o lançamento geral. Um bom exemplo disso é o kernel Linux, que foi lançado pela primeira vez como versão 0.01 em 1991, e levou até 1994 para alcançar a versão 1.0.0.

Os desenvolvedores do emulador de jogos de arcade MAME nunca pretendem lançar uma versão 1.0 do programa porque sempre haverá mais jogos de arcade para emular e, portanto, o projeto nunca poderá ser realmente concluído. Consequentemente, a versão 0.99 foi seguida pela versão 0.100.

Como a Internet se espalhou, a maioria dos fornecedores de software comercial não segue mais a máxima de que uma versão principal deve ser "completa" e, em vez disso, confia em patches com correções de bugs para resolver os problemas conhecidos para os quais uma solução foi encontrada e pode ser corrigida.

Números de versão como marketing

Uma prática relativamente comum é dar grandes saltos nos números das versões por motivos de marketing. Às vezes, os fornecedores de software simplesmente ignoram a versão 1.0 ou lançam rapidamente uma versão com um número de versão subsequente porque o software 1.0 é considerado por muitos clientes muito imaturo para confiar em implantações de produção. Por exemplo, como no caso do dBase II , um produto é lançado com um número de versão que implica que ele está mais maduro do que realmente é.

Outras vezes, os números de versão são aumentados para coincidir com os dos concorrentes. Isso pode ser visto em muitos exemplos de numeração de versão de produto da Microsoft, America Online , Sun Solaris , Java Virtual Machine , SCO Unix, WordPerfect . O Microsoft Access saltou da versão 2.0 para a versão 7.0, para corresponder ao número da versão do Microsoft Word .

A Microsoft também tem sido alvo de versões "catch-up", com os navegadores Netscape pulando a versão 5 para 6, em linha com o Internet Explorer da Microsoft , mas também porque o pacote de aplicativos Mozilla herdou a versão 5 em sua string de agente de usuário durante a pré-1.0 desenvolvimento e o Netscape 6.x foram construídos sobre a base de código da Mozilla.

Outro exemplo de acompanhar os concorrentes é quando o Slackware Linux saltou da versão 4 para a versão 7 em 1999.

Eliminando o elemento mais significativo

O Java da Sun às vezes teve um sistema híbrido, onde o número da versão interna sempre foi 1. x, mas foi comercializado por referência apenas ao x :

  • JDK 1.0.3
  • JDK 1.1.2 a 1.1.8
  • J2SE 1.2.0 ("Java 2") a 1.4.2
  • Java 1.5.0, 1.6.0, 1.7.0, 1.8.0 ("Java 5, 6, 7, 8")

A Sun também abandonou o primeiro dígito para Solaris, onde Solaris 2.8 (ou 2.9) é referido como Solaris 8 (ou 9) em materiais de marketing.

Um salto semelhante ocorreu com o kit de construção de PBX de código aberto Asterisk no início de 2010, cujos líderes de projeto anunciaram que a versão atual 1.8.x logo seria seguida pela versão 10.

Essa abordagem, criticada por muitos porque quebra o significado semântico das seções do número da versão, foi adotada por um número crescente de fornecedores, incluindo Mozilla (para Firefox).

Superstição

  • O lançamento do Office 2007 do Microsoft Office tinha um número de versão interno 12. A próxima versão, Office 2010, tem uma versão interna de 14, devido a superstições em torno do número 13 . O Visual Studio 2013 é a versão número 12.0 do produto, e a nova versão, Visual Studio 2015, tem a versão número 14.0 pelos mesmos motivos.
  • Roxio Toast foi da versão 12 para a versão 14, provavelmente em um esforço para pular as superstições em torno do número 13.
  • O WordPerfect Office da Corel , versão 13, é comercializado como "X3" ( número romano 10 e "3"). O procedimento continuou na próxima versão, X4. O mesmo aconteceu com o Corel's Graphic Suite (ou seja , CorelDRAW , Corel Photo-Paint ), bem como com seu software de edição de vídeo "Video Studio".
  • A Sybase pulou as versões principais 13 e 14 em seu produto de banco de dados relacional Adaptive Server Enterprise, passando de 12.5 para 15.0.
  • O ABBYY Lingvo Dictionary usa a numeração 12, x3 (14), x5 (15).
  • O SUSE Linux Enterprise ignorou as versões 13 e 14 após a versão 12 e lançou diretamente o SLES 15 em julho de 2018.

Cultura geek

  • O SUSE Linux distribuição começou na versão 4.2, para fazer referência a 42 "a resposta à pergunta final da vida, o universo e tudo" mencionado em Douglas Adams " O Guia do Mochileiro das Galáxias .
  • Uma distribuição Slackware Linux teve a versão 13.37, referenciando leet .
  • Finnix pulou da versão 93.0 para 100, em parte para cumprir a afirmação "Não Haverá Finnix '95", uma referência ao Windows 95 .
  • A especificação Tagged Image File Format usou 42 como número de versão interno desde seu início, seus designers não esperavam alterá-lo mais durante seu (ou seu) tempo de vida, uma vez que entraria em conflito com suas diretivas de desenvolvimento.

Superando dificuldades de marketing percebidas

Em meados da década de 1990, o CMMS de rápido crescimento , Maximo, mudou do Maximo Série 3 diretamente para a Série 5, pulando a Série 4 devido às dificuldades de marketing percebidas desse número no mercado chinês, onde o número 4 está associado à "morte" (ver tetrafobia ). Isso, no entanto, não impediu o lançamento do Maximo Series 5 versão 4.0. (O controle de versão da "Série" foi abandonado, redefinindo efetivamente os números da versão após o lançamento da versão 1.0 da Série 5.)

Significado na engenharia de software

Os números de versão são usados ​​em termos práticos pelo consumidor, ou cliente , para identificar ou comparar sua cópia do produto de software com outra cópia, como a versão mais recente lançada pelo desenvolvedor. Para o programador ou empresa, o controle de versão é frequentemente usado em uma base de revisão por revisão, onde partes individuais do software são comparadas e contrastadas com revisões mais novas ou mais antigas dessas mesmas partes, geralmente em um sistema de controle de versão colaborativo .

No século 21, mais programadores começaram a usar uma política de versão formalizada, como a política de versão semântica. O objetivo de tais políticas é tornar mais fácil para outros programadores saberem quando as alterações no código podem danificar coisas que eles escreveram. Essas políticas são especialmente importantes para bibliotecas e estruturas de software , mas também podem ser muito úteis para seguir aplicativos de linha de comando (que podem ser chamados de outros aplicativos) e, na verdade, quaisquer outros aplicativos (que podem ter scripts e / ou estendidos por terceiros )

O controle de versão também é uma prática necessária para permitir muitos esquemas de aplicação de patches e atualização de software, especialmente para decidir automaticamente o que e para onde atualizar.

Importância no suporte técnico

Os números de versão permitem que as pessoas que fornecem suporte determinem exatamente qual código um usuário está executando, para que possam descartar bugs que já foram corrigidos como a causa de um problema e assim por diante. Isso é especialmente importante quando um programa tem uma comunidade de usuários substancial, especialmente quando essa comunidade é grande o suficiente para que as pessoas que fornecem suporte técnico não sejam as pessoas que escreveram o código. O significado semântico da numeração de estilo version.revision.change também é importante para a equipe de tecnologia da informação, que frequentemente a usa para determinar quanta atenção e pesquisa eles precisam prestar a uma nova versão antes de implantá-la em suas instalações. Como regra geral, quanto maiores as mudanças, maiores as chances de que algo possa quebrar (embora o exame do Changelog, se houver, possa revelar apenas mudanças superficiais ou irrelevantes). Esta é uma das razões para o desgosto expresso na abordagem de "largar a versão principal" adotada por Asterisk et alia: agora, a equipe deve (ou pelo menos deveria) fazer um teste de regressão completo para cada atualização.

Números de versão para arquivos e documentos

Alguns sistemas de arquivos de computador , como o sistema de arquivos OpenVMS , também mantêm versões de arquivos.

O versionamento entre documentos é relativamente semelhante à rotina usada com computadores e engenharia de software, onde a cada pequena mudança na estrutura, conteúdo ou condições, o número da versão é incrementado em 1, ou um valor menor ou maior, novamente dependendo do pessoal preferência do autor e o tamanho ou importância das alterações feitas.

Sistemas de pedido de número de versão

Os números de versão evoluem muito rapidamente de inteiros simples (1, 2, ...) para números racionais (2.08, 2.09, 2.10) e, em seguida, para "números" não numéricos, como 4: 3.4.3-2. Esses números de versão complexos são, portanto, melhor tratados como cadeias de caracteres. Os sistemas operacionais que incluem recursos de gerenciamento de pacotes (como todas as distribuições não triviais de Linux ou BSD ) usarão um algoritmo específico de distribuição para comparar os números de versão de diferentes pacotes de software. Por exemplo, os algoritmos de ordenação do Red Hat e distribuições derivadas diferem daqueles das distribuições do tipo Debian.

Como um exemplo de comportamento de implementação de ordenação de número de versão surpreendente, no Debian, zeros à esquerda são ignorados em partes, de forma que 5.0005 e 5.5 são considerados iguais e 5.5  <  5.0006. Isso pode confundir os usuários; ferramentas de correspondência de strings podem falhar em encontrar um determinado número de versão; e isso pode causar erros sutis no gerenciamento de pacotes se os programadores usarem estruturas de dados indexadas por string, como tabelas hash indexadas por número de versão .

Para facilitar a classificação, alguns pacotes de software representam cada componente do esquema major.minor.release com uma largura fixa. Perl representa seus números de versão como um número de ponto flutuante; por exemplo, a versão 5.8.7 do Perl também pode ser representada como 5.008007. Isso permite que uma versão teórica de 5.8.10 seja representada como 5.008010. Outros pacotes de software empacotam cada segmento em uma largura de bit fixa; por exemplo, no Microsoft Windows, o número da versão 6.3.9600.16384 seria representado como hexadecimal 0x0006000325804000. O esquema de ponto flutuante é interrompido se qualquer segmento do número da versão exceder 999; um esquema binário compactado empregando 16 bits cada se quebra após 65535.

Use em outras mídias

Os números de versão do tipo de software podem ser encontrados em outras mídias.

Em alguns casos, o uso é uma analogia direta (por exemplo: Jackass 2.5 , uma versão do Jackass Número Dois com recursos especiais adicionais; o segundo álbum do Garbage , intitulado Versão 2.0 ; ou Dungeons & Dragons 3.5, onde as regras foram revisadas a terceira edição, mas não tanto a ponto de ser considerada a quarta).

Mais frequentemente, é usado para jogar em uma associação com alta tecnologia e não indica literalmente uma 'versão' (por exemplo, Tron 2.0 , um videogame subsequente ao filme Tron ou a série de televisão The IT Crowd , que se refere ao segunda temporada como versão 2.0). Um uso particularmente notável é a Web 2.0 , referindo-se a sites do início dos anos 2000 que enfatizavam o conteúdo gerado pelo usuário , usabilidade e interoperabilidade .

Veja também

Notas

Referências

links externos