Como funciona o Ciclo de Lançamento do WordPress

Um ciclo de lançamento geralmente dura cerca de 4 meses desde a reunião de escopo inicial até o lançamento da versão.

O projeto WordPress é executado por uma equipe de liderança principal e liderado pelo co-fundador e desenvolvedor Matt Mullenweg.

A equipe governa todos os aspectos do projeto, incluindo o desenvolvimento principal, o WordPress.org e as iniciativas da comunidade.

Contribuidores de confiança e desenvolvedores principais ganham mais do que suas habilidades e ações.

Os papéis de liderança são conquistados com base no profissionalismo, personalidade, atitude e respeito entre os pares.

Os melhores colaboradores naturalmente respeitam e assinam as principais filosofias do projeto.

A falta de uma agenda pessoal é fundamental: todos fazemos parte da mesma comunidade e todos compartilhamos objetivos comuns.

Isso não significa que você não pode ter uma opinião – longe disso.

Os melhores colaboradores podem equilibrar suas opiniões com os objetivos do projeto e as perspectivas de usuários e desenvolvedores. Oferecer consistentemente boas sugestões, demonstrar uma forte capacidade de colaborar com outras pessoas e ser capaz de aceitar (e fornecer) feedback são todos importantes.

Você pode identificar esses padrões em alguns dos nossos melhores colaboradores principais, e é por isso que eles exercem forte influência sobre o projeto.

As decisões finais são tomadas pela equipe principal, que evoluiu ao longo da vida do projeto com base no mérito.

Como funciona o Clico de Lançamento

Um ciclo de liberação segue o seguinte padrão:

  • Fase 1: Planejando e protegendo os líderes da equipe. Isso é feito no canal #core. O líder da versão discute os recursos da próxima versão do WordPress. Os colaboradores do WordPress se envolvem com essa discussão. O lead de versão identificará os leads de foco para cada um dos recursos.
  • Fase 2: O trabalho de desenvolvimento começa. Os líderes em foco reúnem equipes e trabalham em seus recursos atribuídos. Bate-papos regulares estão programados para garantir que o desenvolvimento continue avançando.
  • Fase 3: Beta. Os beta são lançados e os beta-testers são solicitados a começar a relatar bugs. Não são permitidas mais confirmações para novos aprimoramentos ou solicitações de recursos para o restante do release.
  • Fase 4: Liberar candidato. Há um congelamento de cadeia a partir deste ponto. O trabalho é direcionado apenas a regressões e bloqueadores.
  • Fase 5: Lançamento. A versão do WordPress é lançada e disponibilizada no Admin do WordPress para atualizações.

O lançamento geralmente é seguido logo após uma versão menor (também conhecida como versão pontual), conforme os bugs são relatados e esmagados.

Uma versão secundária destina-se a correções de bugs e aprimoramentos que não adicionam novos arquivos implantados e ficam a critério do líder da versão com sugestões / informações dos mantenedores e testadores de componentes.

No WordPress os novos recursos são plugins

O modelo Features as Plugins foi introduzido na versão 3.7 como o caminho para o desenvolvimento de recursos para inclusão no núcleo do WordPress.

Esse modelo permite que um recurso seja construído, testado, refinado e polido antes de ser considerado um candidato para ser incluso oficialmente no WordPress.

Os recursos que estão sendo testados como plugins em andamento podem ser rastreados em uma página dedicada do blog Make WordPress Core.

Como surgem os novos recursos do WordPress

Um membro da comunidade ou um novo colaborador, como você, pode propor uma idéia para um novo plug-in de recurso durante o Chat de Plug-in de Recurso, geralmente realizado na época em que um novo ciclo de lançamento é iniciado.

O bate-papo é para apresentar uma idéia que você tem e planejar assumir um papel ativo e principal no desenvolvimento. Outros colaboradores interessados em sua ideia podem participar do esforço.

A data e a hora do bate-papo são anunciadas em uma postagem no blog Make / Core e idéias são adicionadas nos comentários na forma de uma breve proposta:

  • Uma breve visão geral (um parágrafo) da sua proposta de plug-in de recursos.
  • Status atual do plug-in (estágio de idéia, estágio de planejamento, em desenvolvimento, plug-in de recurso existente, trabalho anterior etc.).
  • Uma lista das pessoas envolvidas ou já interessadas no seu plug-in de recursos (incluindo você).
  • Com o que você gostaria de ajuda (escopo, planejamento, wireframing, desenvolvimento, design etc.).

O período de desenvolvimento do plug-in de recurso permite a experimentação e, dependendo da complexidade do plug-in, pode levar vários ciclos de lançamento para ser concluído antes de estar pronto para apresentar à equipe Core como um candidato de mesclagem.

Sem experimentação, algumas idéias podem não ser desenvolvidas em recursos potenciais.

Mas a experimentação também pode levar a um recurso com escopo completo ou até mesmo totalmente desenvolvido que nunca entra no núcleo porque, depois de detalharmos os detalhes, percebemos que o recurso não é algo que pertence ao núcleo.

Não deixe que isso o desencoraje: tentativa e erro fazem parte do processo e resultarão em melhores recursos e em um WordPress melhor.

Os recursos que não são incluídos no núcleo podem continuar funcionando como plug-ins incríveis, e todo o ecossistema se beneficia.

No passado, a equipe principal sugeria que um recurso fosse iniciado como um plugin de qualquer maneira; este processo está formalizado.

Numeração de versão

Uma versão principal do WordPress é ditada pelas duas primeiras sequências. Por exemplo, 3.5 é uma versão principal. O mesmo vale para 3,6, 3,7, até 4,0. A versão 4.0 não é diferente de 3.9 e 4.1. Não existe um “WordPress 3” ou “WordPress 4” – somos estranhos assim por razões históricas.

Os principais lançamentos adicionam novos recursos ao usuário e APIs do desenvolvedor.

Embora normalmente uma versão “principal” signifique que você pode quebrar a compatibilidade com versões anteriores (e, de fato, normalmente significa que sim), o WordPress se esforça para nunca quebrar a compatibilidade com versões anteriores.

É uma das filosofias mais importantes e facilita muito as atualizações para usuários e desenvolvedores.

Uma versão secundária do WordPress é ditada pela terceira sequência. A versão 3.9.1 é uma versão secundária. O mesmo vale para 3.8.2. Uma versão secundária destina-se a correções de bugs e aprimoramentos que não adicionam novos arquivos implantados e ficam a critério do líder da versão com sugestões / informações dos mantenedores e confirmadores de componentes.

Como novas versões do WordPress são lançadas com tanta frequência – buscamos por 4-5 meses para uma versão principal e versões menores acontecem conforme necessário – só precisamos de versões principais e secundárias. Não temos versões de correção ou bug que você normalmente vê com um número de versão no estilo X.Y.Z. Em vez disso, temos um número de versão X.X.Y.

É assim que funcionam os ciclos de release do WordPress.

Um abraço!

Deixe uma resposta