A confusão dos Release Candidates

Com a saída do Firefox 3.5 ontem (já instalaram? Se usam “a internet” para aceder a sites, estão desesperadamente a precisar de o fazer…), vi alguma confusão em blogs sobre Release Candidates (RCs), tendo, por exemplo, lido afirmações como “quem estava a usar a RC1 teve a versão final uma semana antes”.

Isso é um erro, se bem que é compreensível (já lá vamos).

A ideia, no desenvolvimento de software, é lançar versões alfa, que não têm todas as funcionalidades, seguidas de versões beta, que têm problemas conhecidos (mas servem para testar o que supostamente já funciona). Finalmente, sai um RC, chamado “RC1″, que, como o nome diz, é um candidato à versão final.

É essa a ideia do nome. Se não se detectar nenhum problema, será essa a versão final. Caso se detecte, corrige-se e lança-se um RC2. E assim sucessivamente.

Se a versão final for diferente do último RC, isso significa que há algo nela que ainda não está testado, que pode ser muito pouco, mas continua a existir. Por exemplo, detecta-se um bug no RC3, corrige-se esse bug, e lança-se a versão final; isso implica que não houve nenhum teste da correcção desse bug (incluindo como ela interage com o resto do código). O correcto seria lançar um RC4 com esse bug corrigido; se esse RC “sobreviver” a uns dias de teste, então ele transforma-se na versão final.

Porque é que há tanta confusão? Por duas razões.

Uma delas é que muitos developers de software não usam os termos da forma correcta. Em vez de um RC ser efectivamente um candidato à versão final, muitos usam o termo para significar apenas “o que vem depois da beta”, ou seja, algo já relativamente estável e completo. Ou seja, lançam os primeiros RCs sem estarem minimamente à espera de que sejam finais. Para mim, isso não faz qualquer sentido; se não é um candidato a release, não devia ser descrito como tal.

A outra razão, talvez mais aceitável, é que a única coisa que muda do último RC para a versão final é o “branding”, isto é, o número da versão. Ou seja, os RCs estão identificados como tal, e quando um deles sobrevive aos testes, muda-se a versão e lança-se exactamente o mesmo código, apenas a dizer algo diferente no Help:About.

Isto já faz mais sentido, mas ainda acho que não é a melhor forma de desenrolar o processo, além de que provoca confusão. Daí, quando alguém faz a coisa bem feita, as pessoas não percebem e pensam que tiveram a versão final com antecedência por estarem a usar a beta e RCs, quando o que na verdade se passou é que os RCs foram lançados efectivamente como candidatos, sem dizerem “RC” em lado nenhum. O RC1 teve problemas, lançaram o RC2, esse portou-se bem, e é a versão final.

Posts possivelmente relacionados:

  1. Opera 10.50 e JavaScript Alguém já reparou na velocidade do JavaScript no Opera 10.50...
  2. Ubuntu 9.10 (Karmic Koala) no servidor Vi há dias no Planet Ubuntu um dos developers a...
  3. Nova ferramenta: Fantasy Name Generator Isto não é mais do que uma versão web-based de...
  4. sites.dehumanizer.com/computers/ … em Português (brasileiro)! Mais uma versão traduzida. É a fama! Hmm, talvez faça...
  5. E recomeça… Como diz aqui, houve um ligeiro problema técnico, há umas...

Etiquetas: ,

5 Comentários a “A confusão dos Release Candidates”

  1. Disseste aqui umas boas verdades, e já me aconteceu em alguns casos as versões RC serem mais estáveis que a versão final, especialmente porque se tenta enfiar código novo a pressa sem ser testado por se passar directamente de RC2 para Final, só por ser o costume.

  2. O RC2 não terá sido a final, pois houve um RC3 lançado 2 ou 3 dias antes da final… :)

    • Exacto, existiu a RC3.

      Eu fui um dos que levou com o auto update para versão final com 3/4 dias de antecedência (e eu tinha o RC2). Estranho não é? Se existiu alguma alteração ou correcção, não sei – mas estou convencido que sim (o facto de ter existido a RC3 diz logo tudo…). O que eu sei é que a data para a release final já estava marcada para dia 30 de junho, o que significava que qualquer alteração ou correcção de última hora deveria ser incluída na versão final e nunca numa rc4 (e todos nós sabemos bem o risco que a Mozilla correria com novo adiamento).

      E como já disse no meu blog, nestas coisas – bem sabemos – nenhuma versão “final” é realmente “final” no sentido próprio do termo, é tão-somente a versão que é considerava como a mais estável estável, a mais testada e que melhor pode ser utilizada sem risco. Claro, tudo isto é subjectivo, especialmente se corrermos variadas configurações de hardware/software das mais variadas máquinas que podemos encontrar neste mundo – daí que nada seja “final” no real sentido do termo.

      Além disso, como também já tive oportunidade de dizer, já não seria a primeira vez que, nas versões anteriores do firefox, era contemplado com um update automático mesmo antes da nova versão se encontrar para download no site oficial. Portanto, a experiência também me demonstra que isso é possível e provável.

      Aliás, o mesmo tem lugar de forma inversa em algumas distribuições linux. Eu fui um dos primeiros a ter e a anunciar a nova versão do Ubuntu 9.04, mesmo antes de ela ter sido anunciada no site oficial, por intermédio dos servidores da darkstar que já estavam preparados para o anúncio. É o que acontece quando se anda atento ;)

      Mas muito bem, se a ideia é fazermos uma tese sobre o que é uma versão RC, sou obrigado a dar-te um pouco de razão, de facto nada impede que uma RC se torne final sem mancha. A questão é que muito mudou e agora é habitual em todos os ramos libertar as versões RC para a comunidade testar em ambientes não controlados – esse é que é o verdadeiro teste. Aí é que de facto entra em campo o verdadeiro e mais intensivo teste do produto. Quantas vezes, no passado, se libertavam versões finais sem serem testadas intensivamente pela comunidade? E aquilo eram versões “estáveis”? Era autênticas vergonhas! Tenho alguns exemplos de algibeira, mas posso só dar o exemplo do Windows 98 (o primeiro) ou do Milenium. Desde então muita coisa mudou. O próprio Windows XP foi uma nódoa antes do SP1. E depois seguiu-se o Vista que, de certa forma, foi um SO feito à pressa depois de um aborto espontâneo do Windows Longhorn (este até chegou a ser libertado para a comunidade a fim de ser testado – será que a MS se assustou?…) e que ninguém chegou a compreender muito bem. Porque será que agora a Microsoft, com o Windows 7, nada se incomoda que a sua versão RC ande por aí indiscriminadamente? É que é extremamente importante recorrer à comunidade. É a única forma de realmente testar um produto a fim de correcções, afinações e alterações que devem ser elaboradas a montante de uma versão dita “final”.

      Portanto uma versão RC, na minha opinião, só muito raramente pode dar directamente e sem mancha a uma versão final. Mas as opiniões são como as sardinhas…

      Cumprimentos.

  3. Carlos Silva diz:

    As Release Candidates foi mais uma invenção da fabulosa microsoft que acabou por contaminar todo o mundo.

    Antigamente havia as versão alfa (versões em desenvolvimento) e as beta para detecção e correção de erros antes de sair a versão final. Este modelo servia perfeitamente, mas tal como já foi dito, actualmente todas as versões servem para adicionar novas funcionalidades.

    Os projectos opensource em geral e as distribuições em particular, costumam ter o péssimo hábito de adicionar novas features nas RCs.

    Penso que o modelo antigo Alfas/betas/”versão final” gerava menos confusão.

    • Eu até acho que faz sentido os RCs; se algo tem problemas conhecidos, chama-se “beta”, se não tem… ainda convinha testar-se um pouco por users normais mas aventureiros.

      O problema é mesmo usar-se mal o conceito (ou seja, estar-se nas tintas para o nome “release candidate“). Se não acham que está bom, chamem-lhe “beta 8″ ou coisa parecida.

      Infelizmente, há quem ache que 8 betas dá “mau aspecto”, mas 4 betas e 4 RCs já não…