Proposta WordPress para alinhar o ciclo de lançamento com o padrão da indústria – Taberna WordPress

Ontem, Francesca Marano abriu uma proposta para alterar as fases do ciclo de lançamento do WordPress. Foi uma recapitulação de uma discussão iniciada em outubro de 2020. O objetivo é alinhar as fases da plataforma com o padrão mais amplo da indústria de desenvolvimento.

Além da nomenclatura, o WordPress seguiu principalmente a indústria de software na forma como ela lida com seu ciclo de lançamento. Seguir uma convenção bem conhecida pode tornar mais fácil para desenvolvedores fora do ecossistema WordPress fazer a transição para ele. Também permitiria aos desenvolvedores seguir os ciclos de outros projetos, muitos dos quais são dependências do WordPress. Esse tipo de padronização é geralmente visto como uma coisa boa em todo o mundo do desenvolvimento de software.

Com base nas discussões em andamento desde outubro, há um consenso sobre a renomeação das fases para alinhá-las com o padrão. A tabela a seguir mostra como cada fase seria renomeada:

Fase Nome atual Nome Proposto
1 Planejando e protegendo líderes de equipe Planejamento Preliminar
2 Trabalho de desenvolvimento começa Alfa
3 Beta Beta
4 Candidato à liberação Candidato a Lançamento
5 Lançamento Liberação geral

No entanto, esta é uma proposta de duas partes. Simplesmente renomear as fases não altera o funcionamento do ciclo de liberação. Para seguir o padrão estritamente, o WordPress também precisaria ser alterado quando o código fosse confirmado.

Como lidar com a fase beta

Há um ponto de discórdia sobre como lidar com o estágio Beta. O padrão não exige nenhuma alteração de código adicional, exceto novas correções de bug introduzidas no início do ciclo. Para o projeto WordPress, isso cria um problema.

O WordPress fará 18 anos este ano. Ao longo dos anos, ele acumulou uma tonelada de bugs antigos. Geralmente, esses problemas são corrigidos posteriormente no ciclo, às vezes durante o estágio Beta. Esses bugs mais antigos podem não ter feito parte da fase de planejamento preliminar, mas isso significa que eles deveriam esperar até a próxima versão entrar? Seguindo estritamente a proposta, eles devem ser colocados em espera.

Também introduziria um congelamento rígido em quaisquer aprimoramentos definidos para o lançamento, mas incompletos.

“Preocupo-me por não estarmos permitindo espaço para bugs mais antigos que não são específicos aos recursos planejados no lançamento”, escreveu Josepha Haden em um comentário sobre a discussão inicial. “Eu também me preocupo que, ao chamar o hard freeze no início do processo, reduzamos muito a janela para inclusão de recursos. Não gosto de nos limitar a apresentar bugs específicos agora, já que isso exclui muitos de nossos colaboradores voluntários. É mais difícil trabalhar em recursos, pois eles são complexos e rápidos, e bugs mais antigos apresentam mais oportunidades para colaboradores casuais. ”

Por outro lado, é possível que uma correção de bug introduza bugs novos e imprevistos. Quanto mais tarde for adicionado durante o Beta, menos provável que tais bugs sejam notados antes da fase de Lançamento Geral. Esperar pelo próximo ciclo fornece mais tempo para o teste.

Um dos benefícios deste sistema é que quase nenhum novo bug seria criado durante o Beta. Isso permitiria aos voluntários direcionar mais esforços para testar e corrigir problemas que surgiram no Alpha.

O WordPress sempre marchou no ritmo de seu próprio tambor. Ele pode seguir os padrões mais de perto, ao mesmo tempo em que se liberta de limites estritos quando faz sentido para o projeto. As correções de bugs da fase beta não destinadas a uma versão específica podem ser tratadas caso a caso. Temos pessoas em posições de liderança que são capazes de fazer essas ligações quando elas aparecem. Com atualizações automáticas para versões menores, estou menos preocupado com bugs de estágio final.

Tonya Mork propôs duas soluções para que o trabalho com defeitos continuasse durante o ciclo de lançamento. Ambos exigiriam que o WordPress se ramificasse em Beta, fornecendo aos contribuidores um caminho para corrigir os bugs.

A primeira proposta exige um congelamento de recursos anterior, proporcionando duas ou três semanas antes do Beta 1. Este período no final da fase Alfa seria exclusivamente dedicado ao trabalho de defeitos.

A segunda solução move esse trabalho de defeito para sobrepor o Beta do release anterior e o Release Candidate. Isso permite que o trabalho continue durante o período entre os principais lançamentos. Também pode encurtar o ciclo geral de versões principais.

Esta segunda solução também é consistente com as idéias de Joost de Valk sobre como lidar com o trabalho com defeitos. “Acho que devemos apenas ramificar mais cedo e manter o porta-malas aberto para negócios normais”, disse ele sobre a proposta. “Dessa maneira, tudo pode ser trabalhado o tempo todo, mas não será incluído na próxima versão, dependendo de quando você o enviar. Tudo bem, todo software de código aberto que conheço no mundo funciona assim, exceto o WordPress. ”

Muitos desenvolvedores de plugins e temas já acham difícil acompanhar quando as mudanças caem nas fases Beta ou Release Candidate. Ter um ponto claro e definido onde as mudanças de terreno irão beneficiar o ecossistema de extensão, também ajudando os usuários finais a longo prazo. Esta segunda solução faria isso.

Também não há nada de errado em combinar as duas soluções. Uma vez que o plano seria ramificar na fase Beta, a segunda solução já está em vigor no ato da ramificação. A verdadeira discussão é se o projeto deve dedicar um período de tempo durante o estágio Alfa que se concentra exclusivamente em correções de bugs.

Os comentários sobre a proposta estão abertos até 20 de janeiro antes de avançarmos para uma decisão final.


A próxima proposta: versionamento semântico, alguém? Qualquer um? Isto está ligado?



Source

Deixe uma resposta

%d blogueiros gostam disto: