Update VKM to version 151

Hab ich auch schon festgestellt 😆
Mach halt Sign-offs kaputt, aber sonst bräuchte man halt nochmal ne Runde PingPong, wenn was geändert werden soll und die Signatur bestehen bleiben soll 🤪

Hab ich auch schon festgestellt :laughing: Mach halt Sign-offs kaputt, aber sonst bräuchte man halt nochmal ne Runde PingPong, wenn was geändert werden soll und die Signatur bestehen bleiben soll :zany_face:

baeuchle commented

2022-11-09 20:23:59 +01:00

(Migrated from github.com)

Was haltet ihr beiden von dieser Lösung? fd16cffffb

Was haltet ihr beiden von dieser Lösung? fd16cffffb25b379c8a7532040dee72195d02376

autinerd commented

2022-11-09 20:41:25 +01:00

(Migrated from github.com)

Erstelle doch einfach eine CHANGELOG-Datei im Hauptverzeichnis, die du dann gleich mit befüllen kannst. Das macht es gleichzeitig auch angenehmer zum Änderungen nachvollziehen, da sich durch Git-Commits hangeln auch nicht ganz so angenehm ist.

Erstelle doch einfach eine `CHANGELOG`-Datei im Hauptverzeichnis, die du dann gleich mit befüllen kannst. Das macht es gleichzeitig auch angenehmer zum Änderungen nachvollziehen, da sich durch Git-Commits hangeln auch nicht ganz so angenehm ist.

9Lukas5 commented

2022-11-09 20:41:40 +01:00

(Migrated from github.com)

Hm interessante Strategie ja 🤔
Also die CHANGELOG Zeile ist relevant für's Parsen des Changelog Inhalts?

Und der Rest mit Linter und Test? Ist das was automatisches oder auch manuell von dir angefügt?

Generell ne simple Lösung um einen Mix aus beidem zu haben: den originalen Commit unverändert lassen und trotzdem die für den Changelog benötigten Zeilen zu haben, ohne mehrmaliges Ping-Pong mit dem Committer zu haben.
Nachteil/Unschön daran: Gibt uU ne Menge leerer Commits. Ist halt die Frage ob das insgesamt die Übersicht in den Commits nicht stört^^

Werden beim Changelog Parsen auch Merge-Commits gelesen? Dann wäre das eventuell eine Option.

Ansonsten wäre ich durchaus auch offen dafür, den Prozess in mehreren Schritten zu machen:

Committer stellt PR
Wenn akzeptiert kommentierst du in nem Markdown Code-Block die gewünschte Commit-Message
Committer macht den amend
Du mergt

Evtl. ja auch so, dass der Committer im PR einfach ne Notiz setzen kann, ob du es einfach selbst ändern sollst, oder lieber ein Ping-Pong gewünscht ist? 🤷

Hm interessante Strategie ja :thinking: Also die `CHANGELOG` Zeile ist relevant für's Parsen des Changelog Inhalts? Und der Rest mit Linter und Test? Ist das was automatisches oder auch manuell von dir angefügt? Generell ne simple Lösung um einen Mix aus beidem zu haben: den originalen Commit unverändert lassen und trotzdem die für den Changelog benötigten Zeilen zu haben, ohne mehrmaliges Ping-Pong mit dem Committer zu haben. Nachteil/Unschön daran: Gibt uU ne Menge leerer Commits. Ist halt die Frage ob das insgesamt die Übersicht in den Commits nicht stört^^ Werden beim Changelog Parsen auch Merge-Commits gelesen? Dann wäre das eventuell eine Option. Ansonsten wäre ich durchaus auch offen dafür, den Prozess in mehreren Schritten zu machen: - Committer stellt PR - Wenn akzeptiert kommentierst du in nem Markdown Code-Block die gewünschte Commit-Message - Committer macht den amend - Du mergt Evtl. ja auch so, dass der Committer im PR einfach ne Notiz setzen kann, ob du es einfach selbst ändern sollst, oder lieber ein Ping-Pong gewünscht ist? :shrug:

9Lukas5 commented

2022-11-09 20:44:06 +01:00

(Migrated from github.com)

@autinerd Wäre zwar schön den Changelog auch automatisch ins Repo abzulegen, aber die Quelle müssten schon die Commits bleiben. Sonst müsste der Changelog ja händisch geführt werden, was lästig ist 😬

@autinerd Wäre zwar schön den Changelog auch automatisch ins Repo abzulegen, aber die Quelle müssten schon die Commits bleiben. Sonst müsste der Changelog ja händisch geführt werden, was lästig ist :grimacing:

Pull request closed

This pull request cannot be reopened because the branch was deleted.

Rows
Columns

Update VKM to version 151 #147

Pull request closed