Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Any notes at all are considered breaking

Offen
  • Stimmt etwas nicht?
#335 0 Kommentare 1 Reaktion 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
38/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Veraltet
Tech-Stack
javascript
Bereich
release

Rechercherichtung

Beginne bei der verlinkten Bedingung in lib/analyze-commit.js und vergleiche anschließend, wie Notizen in writer-opts.js von conventional-changelog-angular erzeugt werden. Reproduziere die Release-Analyse für einen Squashed Commit, der gewöhnliche Notizen und das verschachtelte feat-Beispiel enthält; abgeschlossen ist die Aufgabe, wenn gewöhnliche Notizen kein Breaking-Release mehr verursachen, echte Breaking-Notizen jedoch weiterhin schon.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
JavaScript
Sterne
447
Forks
82
Ø Merge
7 Std. 53 Min.
Gemergte PRs (30 T.)
9

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus semantic-release/commit-analyzer

Alle Issues in semantic-release/commit-analyzer

Ähnliche Issues

Weitere Issues zu JavaScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.