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.

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…