Pular para o conteúdo
Documentação Nomia

Versionamento

O repositório usa uma versão de produto SemVer canónica no package.json da raiz. As versões do frontend Astro, da documentação, do editor Gutenberg e do tema CMS mantêm-se alinhadas com essa versão; plugins CMS com ciclo próprio continuam SemVer-válidos e são registados no manifesto do release.

Uma release de produção é identificada por uma tag anotada X.Y.Z, sem o prefixo v. Tags de pré-release, como 0.54.0-rc.1, executam validação mas não fazem deployment de produção. Não há releases Composer independentes para o plugin Gutenberg.

Para preparar uma nova versão:

Janela do terminal
pnpm release:prepare -- 0.53.7
pnpm release:notes
pnpm release:check

Cada entrada do changelog descreve a versão; a primeira frase dessa descrição — ou o campo opcional Resumo:, ao lado de Tag: e Data: — é o texto que o painel Nomia Release mostra no wp-admin. O pnpm release:notes copia-o para o CMS, pelo que a descrição da versão vive apenas no changelog.

Depois de atualizar o changelog e rever as alterações, criar a tag 0.53.7 e publicar a tag inicia o workflow protegido de release. O workflow valida o commit etiquetado e faz o deployment coordenado, pela ordem, para:

  1. frontend Astro em Cloudflare (nomia-fe);
  2. WordPress em Ploi (nomia-admin);
  3. documentação Starlight em Cloudflare Workers (nomia-docs).

Os três deployments usam o mesmo commit. Os providers não formam uma transação atómica: se uma superfície falhar, a release fica incompleta e deve ser repetida ou revertida para a versão anterior compatível.