Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Any notes at all are considered breaking

Aberta
#335 0 comentários 1 reação 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
3/5
Tempo estimado
1-2 dias
Facilidade para iniciantes
38/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Estagnada
Stack de tecnologia
javascript
Domínio
release

Direção de pesquisa

Comece pela condição vinculada em lib/analyze-commit.js e, em seguida, compare como as notas são produzidas em writer-opts.js do conventional-changelog-angular. Reproduza a análise da release para um commit submetido a squash que contenha notas comuns e o exemplo de feat aninhado; considera-se concluído quando as notas comuns não causarem mais uma release breaking, mas notas breaking genuínas continuarem causando.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

We maintain a custom conventional changelog link that we would like to use with semantic-release, but any time we've tried this, any time we merge a PR it's treated as a breaking change because of this line right here:

(!breaking || (commit.notes && commit.notes.length > 0)) &&

It treats any commit note at all as a breaking change. I'm pretty sure this is because the angular conventional discards all notes unless they are a breaking change https://github.com/conventional-changelog/conventional-changelog/blob/master/packages/conventional-changelog-angular/writer-opts.js#L31-L34 (I checked a few other conventional changelogs and did not see them using the notes field at all).

This breaks our conventional changelog because we maintain detailed notes for each of the commits inside of a squashed commit. We use this in other places to analyze the squashed commits to determine what the correct release type is. For example, if a commit looks like this:

fix: Something small

* feat: Add a feat

Then the correct release for that squashed commit would be a feat. Semantic release has this concept itself when multiple commits are released at once, we do the same thing just at a PR level.

That problematic line above means that any PR that is squashed is treated as a breaking change though, which means we end up having to maintain a separate set of release rules which defeats the whole purpose of creating a conventional-changelog for our org.

IMO that line should be changed to scan for BREAKING CHANGE in the notes instead of default treating the presence of a note s a breaking change.

Linguagem predominante
JavaScript
Estrelas
446
Forks
82
Merge médio
7h 53min
PRs com merge (30d)
9

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de semantic-release/commit-analyzer

Todas as issues de semantic-release/commit-analyzer

Issues semelhantes

Mais issues de JavaScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.