Como funcionam os sistemas de códigos e versões de softwares

Já reparou que praticamente todos os softwares possuem uns “números” e outros “nomes” para lá de esquisitos? Se sim, também já devem ter observado menções acerca dos termos “beta”, “release candidate”, “código-nome”, entre outro “bichos”, aparecem aos montes, especialmente em épocas anteriores ao lançamento de produtos. Embora se passe por desapercebidos pelo público-leigo, é importante para nós – usuários avançados, profissionais e entusiastas – conhecermos um pouco como funciona estes sistemas de códigos e versões…

WINE: 15 anos em estágio de desenvolvimento!

Todo e qualquer produto passam por um processo de fases em seu desenvolvimento, iniciando com a concepção do projeto e finalizando com a sua disponibilidade no mercado (ao menos teoricamente, se considerarmos certos sistemas que nunca funcionam de modo estável). Com os softwares, temos uma situação especial, que está intimamente relacionada com a necessidade de garantir a produtividade e a segurança de quem usa. Para se ter uma ideia, utilizamos os seguintes termos para designar os diferentes estágios de desenvolvimento do software: alpha, beta, release candidate (RC), release to manufacture (RTM) e stable…

Softwares em estágio alpha são aqueles projetos que foram iniciados por desenvolvedores, mas que não possuem praticamente nenhuma condição de uso produtivo. Em poucas palavras, tratam-se de meros “rascunhos”, onde os desenvolvedores inserem os escopos de suas ideias para serem trabalhadas posteriormente. Consequentemente, somente os desenvolvedores especializados se interagem com estes softwares, por possuírem os conhecimentos técnicos necessários para a sua manipulação.

Já o estágio beta está a um passo à frente do alpha. Embora estes softwares ainda não estejam em condições de uso normal, eles já possuem uma definição geral “de como deverão ficar”, assim que as versões para a produtividade forem lançadas. Em termos práticos, os softwares em estágio beta são liberados para o público interessado apenas para fins de testes, onde as avaliações de uso e a reportagem das falhas existentes passam a ser o foco principal do processo de desenvolvimento, embora uns e outros recursos também possam ser acrescentados.

À partir do estágio release candidate (RC), é que poderemos considerar os softwares prontos para o uso em produção, embora não sejam considerados tecnicamente estáveis. Em termos práticos, significa que ainda faltam algumas arestas a serem aparadas, onde os desenvolvedores promovem pequenos ajustes funcionais, estéticos e até mesmo algumas correções de erros, mas que normalmente não afetam o seu funcionamento estável. Não raro, algumas sérias correções de erros são feitas, mas estes são casos à parte, em que geralmente tais procedimentos não são previstos nos cronogramas de desenvolvimento. Enquanto isso, o estágio release to manufacture (RTM) é apenas uma espécie de meio-termo entre o release candidate e o stable, onde os softwares estão prontos, sendo disponibilizados para fabricantes e integradores antes do seu lançamento oficial.

Por fim, vem o estágio stable, que é simplesmente a definição dada aos softwares que percorreram todo o cronograma de desenvolvimento, estando prontos para o lançamento. Apenas neste estágio, o software/produto é considerado pronto para o uso em ambientes de produtividade, embora o estágio caracterizado como RTM em nada difere do stable, além da data de lançamento.

Mesmo estando prontos para o uso em produção, nem sempre os softwares em estágio stable são considerados estáveis “de facto”. Para começar, uma vez disponibilizado para o uso em produção, a quantidade de usuários será muito superior se comparado aos poucos usuários que o experimentaram em seu estágio beta. Assim, muitas falhas que antes se passaram por desapercebidas, são encontradas. Então, entra em cena as atualizações de correção, as quais veremos mais à frente…

Para a grande maioria dos softwares livres (e alguns comerciais), um segundo sistema de controle de versões passará à vigorar, a partir do seu lançamento. Por exemplo, os usuários que clicarem no menu principal ? Ajuda ? Sobre (dependendo do software), verão um valor numérico que acompanha o nome do produto. Tomemos como exemplo o OpenOffice.org, em sua atual versão 3.2. O primeiro dígito representa o major release, ao passo que o segundo dígito representa o minor release. Em nosso caso, o OpenOffice.org está em sua terceira versão (major release), acompanhado de dois updates (minor release).

Quando um software é lançado pela primeira vez, ele recebe a típica versão 1.0. Enquanto isso, os desenvolvedores continuam a trabalhar nas novas versões deste software, que certamente irá se tornar a futura versão final 2.0. Esta designação (major release) é geralmente utilizada quando a nova versão do software recebe grandes modificações, à ponto de se tornar bem diferenciada ou até mesmo incompatível com a versão anterior. Os softwares comerciais são lançados periódicamente baseados neste sistema, já que necessitam convencer os seus usuários que a aquisição de uma licença de uso se faz necessária, em virtude da grande quantidade de novos recursos oferecidos, se comparado com a versão anterior.

Nem sempre, as novas versões dos softwares apresentam tantas mudanças expressivas, à ponto de sugerir uma nova numeração do tipo major release. Por exemplo, poderemos ter novas versões de um navegador que apenas recebeu um melhor suporte a uma tecnologia ou acrescentou o uso de alguns simples recursos, mas que continua sendo exatamente o mesmo, se comparado à versão anterior (mas que precisa ser diferenciado). Neste caso, entra em cena o minor release, que é uma segunda numeração usada para realizar este controle. Por exemplo, para um software na versão 1.0 que teve recentes melhorias adicionadas, ele passaria para a versão: 1.1; se houvesse outras novas melhorias, esta versão seria 1.2; e assim, sucessivamente. Esta prática é aplicada a softwares livres em geral, que por razões mercadológicas, não precisam prover grandes mudanças para justificarem uma aquisição de licença (já que eles não são vendidos).

Lembram quando comentei sobre aquelas falhas que, se passaram por desapercebidas assim que o software foi lançado, mas logo foram encontradas? Pois bem: para estas situações, são aplicadas as correções de segurança, que por sua vez são incorporadas ao software recém-lançado. E para diferenciar um aplicativo que recebeu as atualizações de outro recém-lançado, o sistema de controle de versões recebe o terceiro dígito. Por exemplo, o nosso software-conceito receberia a versão 1.2.1, se algumas falhas de segurança forem corrigidas; 1.2.2, para outras correções necessárias; e assim, sucessivamente!

Basicamente, estes são os procedimentos padronizados para o gerenciamento de softwares e as suas versões. Embora simples, eficiente e extremamente funcional, isto não quer dizer que todo software deverá seguir à risca estas regras: especialmente no cenário do software livre, veremos inúmeros casos em que outras práticas são adotadas, onde estas geralmente baseiam-se nos padrões já estabelecido. Por exemplo, o GNOME reserva as numerações minor release pares para o gerenciamento das versões estáveis (p. ex. 2.24.0, 2.28.1, etc.) e as versões ímpares para o desenvolvimento. Idem para o kernel Linux, que há tempos pulou da série 2.4.X para a 2.6.X.

Em outros casos, um quarto dígito poderá ser aplicado, como é o caso do próprio kernel Linux. Antes do lançamento da versão 2.6.37, a versão era 2.6.36.2, onde o último número indica a aplicação de correções sérias na segurança. Tecnicamente, deveria mantido o esquema de 3 números, já que o terceiro dígito foi criado justamente para esta finalidade (correção de erros e falhas de segurança); entretanto, dada as características únicas do Linux (ele é um kernel que gerencia todos os recursos computacionais e não um simples software, que pode ficar recebendo novas versões à todo o instante), a aplicação deste simples – mas eficiente – sistema de numeração se tornou bastante aceita.

Para nós – um público-alvo que varia de simples usuários e bons administradores de sistemas – este sistema de códigos e versões de software funciona maravilhosamente bem, nos dando a possibilidade de realizar um gerenciamento mais prático e efetivo dos softwares instalados em nossos PCs desktops (ou notebooks & netbooks). No entanto, para os desenvolvedores de softwares, tal metodologia apenas facilita apenas o trabalho de realizar lançamentos de softwares, mas não de administrar as diferentes implementações que eles vão recebendo ao longo do tempo. Em se tratando de projetos de porte considerável, onde há uma equipe de desenvolvedores trabalhando simultaneamente e gerando muitas linhas de código, as coisas se complicam ainda mais.

Para esta turma, existem os Sistemas de Controle de Versão…

“Um sistema de controle de versão (ou versionamento), VCS (do inglês version control system) ou ainda SCM (do inglês source code management) na função prática da Ciência da Computação e da Engenharia de Software, é um software com a finalidade de gerenciar diferentes versões no desenvolvimento de um documento qualquer. Esses sistemas são comumente utilizados no desenvolvimento de software para controlar as diferentes versões – histórico e desenvolvimento – dos códigos-fontes e também da documentação.” — [by Wikipedia].

Mas dada a complexidade do assunto, quem sabe fica para uma próxima oportunidade? &;-D

Por Ednei Pacheco <ednei.pacheco [at]gmail.com>

http://www.darkstar.eti.br/