Skip to main content

Semantic release

  • Semantic release

  • A posição dos pacotes no .releaserc importa

"plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/changelog",
    "@semantic-release/release-notes-generator",
    ["@semantic-release/npm", { "npmPublish": false}],
    ["@semantic-release/git",
    {
      "assets": ["package.json", "package-lock.json", "CHANGELOG.md", "pubspec.yaml"],
      "message": "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
    }],
    "@semantic-release/github",
    [
      "@semantic-release/exec",
      {
        "prepareCmd": "echo \"NEXT_RELEASE_VERSION=${nextRelease.version}\" >> $GITHUB_ENV"
      }
    ]
  ]

//ordem que funciona, caso esteja diferente pode ocorrer de não atualizar os arquivos

Dry-Run​

A opção "dry-run" do Semantic Release é uma funcionalidade que permite simular o processo de lançamento sem realmente executá-lo. Em vez de publicar uma nova versão do seu projeto, o "dry-run" realiza todas as etapas do Semantic Release, como determinar a próxima versão, gerar notas de lançamento e atualizar arquivos de manifesto, mas sem efetuar as alterações no seu projeto.

O objetivo principal do "dry-run" é verificar o resultado do processo de lançamento antes de executá-lo oficialmente. Isso pode ajudar a identificar possíveis problemas ou erros que podem ocorrer durante o lançamento real, permitindo que você revise as alterações geradas e avalie se estão corretas.

Com o "dry-run", você pode ver as notas de lançamento geradas, verificar as alterações planejadas nos arquivos de manifesto (como package.json ou pubspec.yaml) e revisar as alterações propostas antes de executar o Semantic Release para um lançamento real. Isso pode ser especialmente útil em pipelines de integração contínua (CI/CD), onde você deseja ter uma visão prévia do resultado do lançamento antes de ativá-lo.

Ao executar o Semantic Release com a opção "dry-run", geralmente usa-se um comando semelhante ao seguinte:

semantic-release --dry-run

Dessa forma, o Semantic Release executa todas as etapas do processo de lançamento em modo simulado, fornecendo informações detalhadas sobre as alterações planejadas e a próxima versão sem afetar seu projeto.

Lembre-se de que o "dry-run" não faz alterações reais no seu projeto. É uma maneira de verificar as ações propostas pelo Semantic Release antes de aplicá-las.

Explicação​

  • Versão MAJOR (X.y.z): Alterações de API incompatíveis.
  • Versão MINOR (x.Y.z): Funcionalidade compatível com versões anteriores.
  • Versão PATCH (x.y.Z): Correções de bugs compatíveis com versões anteriores.

Metadados de pré-lançamento e compilação adicionam mais detalhes:

  • Pré-lançamento: 1.0.0-alpha.
  • Metadados de compilação: 1.0.0+build.1.

O incremento de versões segue regras claras:

  • MAJOR: Alterações incompatíveis. Redefina MINOR e PATCH para 0.
  • MINOR: Nova funcionalidade. Redefina PATCH para 0.
  • PATCH: Correções de bugs.

Os intervalos de versão ajudam a gerenciar dependências:

  • Exato: 1.2.3 corresponde apenas a 1.2.3.
  • Maior/Menor que: >1.2.3, <1.2.3.
  • Til (~): ~1.2.3 corresponde a >=1.2.3 <1.3.0.
  • Caret (^): ^1.2.3 corresponde a >=1.2.3 <2.0.0.

Intervalos hifenizados e intervalos combinados oferecem flexibilidade:

  • 1.2.3 - 2.3.4 corresponde a >=1.2.3 <=2.3.4.
  • AND: Separado por espaços (por exemplo, >=0.14 <16).
  • OR: Separado por barras verticais (por exemplo, 0.14.x || 15.x.x).

Lembre-se destes princípios:

  • Compatibilidade com versões anteriores: Evite quebrar a API, a menos que seja uma alteração importante.
  • Clareza e previsibilidade: os números de versão devem transmitir claramente a natureza das mudanças.

Melhores práticas:

  • Documentar mudanças em um changelog.
  • Usar ferramentas automatizadas para gerenciamento de versões.
  • Comunicar mudanças de última hora claramente.