Versionamento de software é o processo onde atribui nomes de versão ou números de versão, sendo estes únicos, para estados de um software.
Existe uma determinada categoria de números de versão (maior, menor), esses números são definidos em ordem crescente e correspondem a uma nova alteração no desenvolvimento do software. Em um nível mais detalhado, o controle de revisão é usado para rastrear o progresso das versões de uma informação eletrônica, sendo ela um software ou não.
Esquemas de versionamento de softwares
Vários esquemas de numeração de versão têm sido criados para rastrear as diferentes versões de uma parte do software. Esses esquemas são usados não somente para softwares, mas também em outros contextos fora da computação.
Identificador baseado em sequência
No esquema de versionamento de software baseado em sequência, a cada release do software é atribuído um identificador único que consiste em uma ou mais sequências de números e letras. Essa é o padrão, entretanto, os esquemas podem variar em várias formas tais como: na quantidade de sequências, na definição da importância com relação às diferentes sequências e na forma de incrementar as sequências.
Variação de importância
Em alguns sistemas, os identificadores baseados em sequência são utilizados para repassar a importância das alterações entre os releases: As alterações são classificadas por nível de importância do release, dessa forma a decisão de qual sequência utilizar entre as liberações é baseada na importância das alterações com relação à importância da liberação anterior, onde a primeira sequência será modificada para as mudanças mais importantes, e as mudanças após a primeira sequência representam mudanças com importância menor.
Por exemplo, em um esquema que se utiliza uma sequência com 4 identificadores, a primeira sequência só pode ser incrementada quando o código é totalmente reescrito, enquanto uma mudança de interface do usuário ou da documentação justifica a alteração apenas da quarta sequência.
Essa prática permite aos usuários (ou usuários em potencial) avaliar em um teste real o nível da alteração que um software sofreu. Se as alterações são feitas entre, digamos 1.3rc4 e o release de produção 1.3, então com relação aquele release, podemos afirmar que teve uma produção específica para testes reais de nível qualidade e que essas alterações, de fato, não têm necessidade de serem testadas por todos os integrantes do mundo real.
Esse tipo de alteração abrange normalmente o terceiro nível de numeração (“mudanças”), mas não se aplica esse nível de rigor para que as alterações recebam o número: 1.3.1, 1.3.2, 1.3.3, 1.3.4 ... 1.4b1, etc. 1.4b1, etc.
Em princípio o maior número é aumentado quando há saltos significativos de funcionalidade, o menor número é incrementado apenas quando pequenas funcionalidades ou correções significativas são adicionadas e o número da revisão é incrementado quando pequenos bugs são corrigidos.
Um produto típico poderia utilizar os números 0.9 (para a versão beta do software), 0.9.1, 0.9.2, 0.9.3, 1.0, 1.0.1, 1.0.2, 1.1, 1.1.1, 2.0, 2.0.1, 2.0. 2, 2.1, 2.1.1, 2.1.2, 2.2, etc. Desenvolvedores têm por vezes que saltar da versão 5.0 para a versão 5.5 para indicar que foram adicionadas funcionalidades importantes que não justificam o incremento da versão principal, que seria abusiva.
Uma abordagem diferente é utilizar os maiores e menores números juntamente com uma sequência alfanumérica denotando o tipo da liberação, tais como: alfa, beta ou candidata a liberação oficial (release candidate, rc). As sucessões de liberações poderiam ser semelhantes 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 (caso for considerada estável) == 1.0. Se encontrar erros em 1.0rc1 que precisam ser corrigidos ele se transformará em 1.0rc2, e assim por diante. A característica importante dessa abordagem é que a primeira versão de um determinado nível (beta, rc ou release) deve ser idêntica a da última versão do release abaixo dela: você não pode realizar qualquer alteração a partir da última versão beta para primeiro RC ou a partir do último RC para a produção. Se fizer isso, deverá passar outro release para um nível inferior.
No entanto, desde que as versões sejam geradas por humanos, e não por computador, não há nada que impeça alterações arbitrárias que impeçam essas regras: por exemplo, a primeira sequência poderia ser incrementada entre as versões de se diferem nem se quer por uma única linha de código, para dar uma (falsa) impressão que alterações muito significativas foram realizadas.
Outros esquemas repassam importância em sequências individuais:
maior.menor [. Build [. revision]] ou major.minor[.maintenance[.build]].
Mais uma vez, neste exemplo, o que constitui uma alteração importante de uma alteração menos importante é totalmente arbitrária e é o autor que define o que é uma build, ou como uma revisão (revision) se difere de uma pequena alteração.
Na maioria dos softwares proprietários, a primeira versão liberada de um produto é a versão 1.
Definindo estágio de desenvolvimento
Alguns esquemas utilizam fazem uso de um zero na primeira sequência para designar os status de liberação alfa ou beta, onde não são totalmente estáveis para uso geral, práticas de implantação, e são destinados para testes ou uso interno.
Pode ser usado na terceira posição:
• 0 para o estado alfa
• 1 para o estado beta
• 2 para candidato a liberação (release candidate)
• 3 para a liberação pública (public release).
Por exemplo:
• 1.2.0.1 ao invés de 1.2-a
• 1.2.1.2 ao invés de 1.2-b2 (beta com alguns bugs corrigidos)
• 1.2.2.3 ao invés de 1.2-rc
• 1.2.3.0 ao invés de 1.2-r (distribuição comercial)
• 1.2.3.5 ao invés de 1.2-r5 (distribuição comercial com correção de vários bugs)
Separando sequências
Quando impressas, as sequências podem ser separadas com caracteres. A escolha dos caracteres e sua utilização variam de acordo com o esquema. A lista seguinte exibe exemplos hipotéticos que esquemas de separação para a mesma liberação (release) (O 13º do terceiro nível da revisão para o 4º do segundo nível da revisão para o 2º do primeiro nível da revisão):
• Um esquema pode usar o mesmo caractere para todas as sequências: 2.4.13, 2/4/13, 2-4-13
• A escolha do esquema de sequência de separações pode ser inconsistente, separando algumas sequências e outras não: 2.413
• A escolha do esquema de caracteres pode ser inconsistente dentro de um mesmo identificador 2.4_13
Quando um ponto é usado para separar as sequências, ele não pode ser representado como um ponto decimal, e as sequências não têm posição significativa. Um identificador 2.5, por exemplo, não é “2 e meio” ou “metade da versão 3”, é o 5º do segundo nível da revisão do 2º do primeiro nível da revisão e não seria adequando ao menos que existisse um 2.1, 2.2, 2.3 e 2.4.
Número de sequências
Existe uma determinada categoria de números de versão (maior, menor), esses números são definidos em ordem crescente e correspondem a uma nova alteração no desenvolvimento do software. Em um nível mais detalhado, o controle de revisão é usado para rastrear o progresso das versões de uma informação eletrônica, sendo ela um software ou não.
Esquemas de versionamento de softwares
Vários esquemas de numeração de versão têm sido criados para rastrear as diferentes versões de uma parte do software. Esses esquemas são usados não somente para softwares, mas também em outros contextos fora da computação.
Identificador baseado em sequência
No esquema de versionamento de software baseado em sequência, a cada release do software é atribuído um identificador único que consiste em uma ou mais sequências de números e letras. Essa é o padrão, entretanto, os esquemas podem variar em várias formas tais como: na quantidade de sequências, na definição da importância com relação às diferentes sequências e na forma de incrementar as sequências.
Variação de importância
Em alguns sistemas, os identificadores baseados em sequência são utilizados para repassar a importância das alterações entre os releases: As alterações são classificadas por nível de importância do release, dessa forma a decisão de qual sequência utilizar entre as liberações é baseada na importância das alterações com relação à importância da liberação anterior, onde a primeira sequência será modificada para as mudanças mais importantes, e as mudanças após a primeira sequência representam mudanças com importância menor.
Por exemplo, em um esquema que se utiliza uma sequência com 4 identificadores, a primeira sequência só pode ser incrementada quando o código é totalmente reescrito, enquanto uma mudança de interface do usuário ou da documentação justifica a alteração apenas da quarta sequência.
Essa prática permite aos usuários (ou usuários em potencial) avaliar em um teste real o nível da alteração que um software sofreu. Se as alterações são feitas entre, digamos 1.3rc4 e o release de produção 1.3, então com relação aquele release, podemos afirmar que teve uma produção específica para testes reais de nível qualidade e que essas alterações, de fato, não têm necessidade de serem testadas por todos os integrantes do mundo real.
Esse tipo de alteração abrange normalmente o terceiro nível de numeração (“mudanças”), mas não se aplica esse nível de rigor para que as alterações recebam o número: 1.3.1, 1.3.2, 1.3.3, 1.3.4 ... 1.4b1, etc. 1.4b1, etc.
Em princípio o maior número é aumentado quando há saltos significativos de funcionalidade, o menor número é incrementado apenas quando pequenas funcionalidades ou correções significativas são adicionadas e o número da revisão é incrementado quando pequenos bugs são corrigidos.
Um produto típico poderia utilizar os números 0.9 (para a versão beta do software), 0.9.1, 0.9.2, 0.9.3, 1.0, 1.0.1, 1.0.2, 1.1, 1.1.1, 2.0, 2.0.1, 2.0. 2, 2.1, 2.1.1, 2.1.2, 2.2, etc. Desenvolvedores têm por vezes que saltar da versão 5.0 para a versão 5.5 para indicar que foram adicionadas funcionalidades importantes que não justificam o incremento da versão principal, que seria abusiva.
Uma abordagem diferente é utilizar os maiores e menores números juntamente com uma sequência alfanumérica denotando o tipo da liberação, tais como: alfa, beta ou candidata a liberação oficial (release candidate, rc). As sucessões de liberações poderiam ser semelhantes 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 (caso for considerada estável) == 1.0. Se encontrar erros em 1.0rc1 que precisam ser corrigidos ele se transformará em 1.0rc2, e assim por diante. A característica importante dessa abordagem é que a primeira versão de um determinado nível (beta, rc ou release) deve ser idêntica a da última versão do release abaixo dela: você não pode realizar qualquer alteração a partir da última versão beta para primeiro RC ou a partir do último RC para a produção. Se fizer isso, deverá passar outro release para um nível inferior.
No entanto, desde que as versões sejam geradas por humanos, e não por computador, não há nada que impeça alterações arbitrárias que impeçam essas regras: por exemplo, a primeira sequência poderia ser incrementada entre as versões de se diferem nem se quer por uma única linha de código, para dar uma (falsa) impressão que alterações muito significativas foram realizadas.
Outros esquemas repassam importância em sequências individuais:
maior.menor [. Build [. revision]] ou major.minor[.maintenance[.build]].
Mais uma vez, neste exemplo, o que constitui uma alteração importante de uma alteração menos importante é totalmente arbitrária e é o autor que define o que é uma build, ou como uma revisão (revision) se difere de uma pequena alteração.
Na maioria dos softwares proprietários, a primeira versão liberada de um produto é a versão 1.
Definindo estágio de desenvolvimento
Alguns esquemas utilizam fazem uso de um zero na primeira sequência para designar os status de liberação alfa ou beta, onde não são totalmente estáveis para uso geral, práticas de implantação, e são destinados para testes ou uso interno.
Pode ser usado na terceira posição:
• 0 para o estado alfa
• 1 para o estado beta
• 2 para candidato a liberação (release candidate)
• 3 para a liberação pública (public release).
Por exemplo:
• 1.2.0.1 ao invés de 1.2-a
• 1.2.1.2 ao invés de 1.2-b2 (beta com alguns bugs corrigidos)
• 1.2.2.3 ao invés de 1.2-rc
• 1.2.3.0 ao invés de 1.2-r (distribuição comercial)
• 1.2.3.5 ao invés de 1.2-r5 (distribuição comercial com correção de vários bugs)
Separando sequências
Quando impressas, as sequências podem ser separadas com caracteres. A escolha dos caracteres e sua utilização variam de acordo com o esquema. A lista seguinte exibe exemplos hipotéticos que esquemas de separação para a mesma liberação (release) (O 13º do terceiro nível da revisão para o 4º do segundo nível da revisão para o 2º do primeiro nível da revisão):
• Um esquema pode usar o mesmo caractere para todas as sequências: 2.4.13, 2/4/13, 2-4-13
• A escolha do esquema de sequência de separações pode ser inconsistente, separando algumas sequências e outras não: 2.413
• A escolha do esquema de caracteres pode ser inconsistente dentro de um mesmo identificador 2.4_13
Quando um ponto é usado para separar as sequências, ele não pode ser representado como um ponto decimal, e as sequências não têm posição significativa. Um identificador 2.5, por exemplo, não é “2 e meio” ou “metade da versão 3”, é o 5º do segundo nível da revisão do 2º do primeiro nível da revisão e não seria adequando ao menos que existisse um 2.1, 2.2, 2.3 e 2.4.
Número de sequências
Existem às vezes 4 números não publicados que indicam a build do software (utilizado pela Microsoft). Algumas empresas incluem ainda a data de realização da build. Versões numeradas podem conter letras e outros caracteres, por exemplo, Lotus 1-2-3 Release 1a.
Incrementando sequências
Existem duas escolas de pensamento de como os números da versão são incrementados: Muitos pacotes de software livre tratam os números da versão como um fluxo contínuo, pois um software livre pode ter números de versão 1.7.0, 1.8.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0, 1.11.1, 1.11.2, etc. Um exemplo é o pacote de software do MediaWiki. No entanto, muitos programas tratam o número de versão de outro modo, eles podem ter números de versão como: 1.8, 1.9, 1.9.1, 1.9.2, etc. Nos pacotes de software que utilizam essa forma de numeração 1.91 é a próxima menor versão depois de 1.9. Releases de manutenção, isto é, correções de bugs, geralmente seriam denominadas como: 1.91a, 1.91b, etc.
Utilizando números negativos
Existem alguns projetos que usam números negativos na versão. Um exemplo é o compilador Smalleiffel que começou a partir de -1.0 e contadas de 0.0 em diante.
Grau de compatibilidade
Alguns projetos utilizam o número maior da versão para indicar releases incompatíveis. Dois exemplos são: Apache TAEG e do FarCry CMS.
Data
O projeto Wine utilizou um esquema de versionamento baseado em datas, nos utiliza o ano, seguido do mês, seguido do dia do lançamento, por exemplo, “Wine 20040505”. O Wine segue atualmente um padrão de liberação por faixa, a versão mais atual a partir de 6 de Junho de 2008 é 1.0-rc4. O Linux Unbutu utiliza um esquema semelhante, Unbutu 8.10, por exemplo, foi liberado em Outubro de 2008.
Ao utilizar datas em versões, por exemplo, nome de arquivo, é comum utilizar o esquema ISO YYYY-MM-DD, pois essa string é facilmente ordenada em ordem crescente e decrescente. Os hífens são geralmente omitidos.
Ano de lançamento
Outros exemplos, identificando versões por ano (Adobe Illusrator 88, Word Perfect Office 2003). Embora quando a data é utilizada para identificar a versão é geralmente para fins de marketing e existe um numero de versão real. Por exemplo, o Microsoft Windows 2000 Server é versionado internamente como NT 5.0. (“NT” é uma referência para o nome original do produto).
Códigos Alfanuméricos
Exemplos:
• Macromedia Flash MX
• Adobe Photoshop CS2
Show velho
ResponderExcluirera o que eu estava precisando
Massa.
ResponderExcluir