Ciclo e anatomia de um release WordPress

Como vocês já estão a acostumados a acompanhar por aqui, vivemos noticiando o lançamento das versões alpha, beta e RC antes de noticiar o lançamento oficial de uma versão nova do WordPress.

Com isso, uma questão me passou pela cabeça: todos acompanham tais notícias, mas será que todos entendem bem como funciona tal ciclo até o lançamento de uma nova versão ?

Fiz algumas pesquisas por aqui para ver se achava alguma declaração oficial de algum membro da equipe de desenvolvimento do WordPress e encontrei um email do Ryan Boren, um dos líderes da equipe de desenvolvimento do WordPress na Automattic, detalhando perfeitamente como funciona esse ciclo neste este email.

Vejamos agora como funciona esse ciclo e a “anatomia” de cada etapa até termos o nossa versão funcional do WordPress.

Versão Alpha

• Coleta de idéias de novas funções no fórum, fóruns de suporte, plugins mais populares, brainstorms dos desenvolvedores e outras fontes.
• Encontro dos desenvolvedores do WordPress para decidir sobre quais funções que os desenvolvedores se comprometerão a criar/redefinr e definir o escopo do lançamento. Enquanto isso, observação do trac para correções de itens da versão anterior.
• Com os novos recursos decidido, criam-se os tickets das tarefas para todos os recursos direcionados para o lançamento. Conjunto de tickets “melhorias” fazem o corte para “tarefa”. Com isso, começa o desenvolvimento dos patches e envio dos mesmos exibidos nos tickets
• Paralelamente, continuar de olho no Trac e o desdobamento de tickets já existentes
• Integração contínua das funções no corpo do sistema, o que dá um belo trabalho pois deve ser feito de forma que não “quebre” o que já existe no sistema.

Congelamento de Funcionalidades (Feature Freeze)

• Uma vez que todos os recursos são considerados completos via reunião da equipe de desenvolvimento (# wordpress-dev), começa o congelamento de funções. Às vezes existem algumas funcionalidades que não estão totalmente prontas, que são apontados como exceções ao congelamento. Tudo o resto é colocado em congelamento de recursos com a esperança de condução para beta em todo o resto. Num ciclo ideal não acontecem tais exceções, mas eventualmente elas acontecem.
• Correção de todos os bugs encontrados dirigindo tal pacote para entrar no ciclo Beta

Versão Beta

• Bugs que impediam o lançamento do beta são corrigidos. Beta 1 é liberado para iniciar o ciclo Beta público.
• Correção de bugs e apontamento de melhorias
• Versão Beta 2 cerca de uma semana depois.
• Correção de bugs e de novos tickets abertos nesse período.
• Versão Beta 3, uma semana depois.
• Correção de bugs.

Release Candidate (RC)

• Lançamento da Versão RC1
• Espera por alguns dias para permitir testes e feedbacks, o que pode variar 1 dia a uma semana.
• Se mais bugs forem detectados, correção dos bugs e lançamento da versão RC2.

Versão Final

• Lançamento Oficial
• Monitoramento dos feedbacks e início da fase de correções para uma versão de manutenção que gerará a próxima versão.

E voltamos para a fase Alpha !