Auto: Benutzerdefinierte Bump-Commit-Nachricht

Ich bevorzuge vielleicht keine Bump-Commits (wie semantic-release tut):

{
  "skipBumpCommit": true
}

Wenn Bump-Commits deaktiviert sind, ist die neueste NPM-Version die Quelle der Wahrheit (oder funktioniert es vielleicht schon so?) Und das Feld "Version" in package.json kann auf 0.0.0-development oder ähnlich gesetzt werden.

ist überspringen CI bei travis anders? ohne das in deinen Commit-Nachrichten kannst du leicht in eine Schleife geraten

auto verwendet die lokale Version und die veröffentlichte Version und wählt die höhere Version aus, um npm-Fehler zu vermeiden. Ist das ausreichend?

ist überspringen CI bei travis anders? ohne das in deinen Commit-Nachrichten kannst du leicht in eine Schleife geraten

Ich bin mir nicht wirklich sicher. Wenn es im Commit-Header erforderlich ist, dann soll es so sein. 😆

auto verwendet die lokale Version und die veröffentlichte Version und wählt die höhere Version aus, um npm-Fehler zu vermeiden. Ist das ausreichend?

Ja wirklich? Schön. Wird in diesem Fall kein Bump-Commit erstellt?

Nein, in diesem Fall stoßen wir die veröffentlichte Version an, da Sie über eine alte Version veröffentlichen können.

Ich kann mir nicht vorstellen, wie skipBumpCommit funktionieren würde oder wie das Endergebnis aussehen würde. Um shipit auszuführen, müssen Sie die Version in irgendeiner Weise ändern, daher kann ich nicht sehen, wie Sie aus diesem Commit herauskommen könnten.

Was halten Sie davon, dass shipit den Bump-Commit überspringt, wenn die Version in package.json so etwas wie 0.0.0-development ?

1. Paket beginnt bei 0.0.0-Entwicklung

2. Sie führen version es gibt den Bump basierend auf PRs zurück, es gibt alles zurück (Patch, Minor, Major) - sagen wir, es ist Patch

3. Changelog-Erstellung - (0.0.0-Entwicklung => 0.0.0). Aber das soll nicht passieren? Stattdessen unter dem Changelog-Titel '0.0.0-development' hinzufügen?

4. Hooks mal veröffentlichen - es würde 0.0.0-development => 0.0.0 bedeuten und veröffentlichen. aber Sie möchten, dass development erkannt wird und der Veröffentlichungsschritt insgesamt übersprungen wird

5. eine Github-Version erstellen - Statt eine neue Version zu erstellen, aktualisieren Sie die alte mit den neuen Commits

6. Paket bleibt bei 0.0.0-Entwicklung bis ??? während sich Veränderungen ansammeln

Zwei Möglichkeiten, wenn Sie das wollen:

1. Führen Sie auto shipit einfach nicht aus, bis Sie mit der Veröffentlichung und Veröffentlichung beginnen möchten. Fügen Sie die Labels dennoch zu Ihren PRs hinzu. Wenn Sie bereit sind, fügen Sie auto shipit zu Ihrem CI-Prozess hinzu und er enthält alle Label-PRs in Ihrer ersten Veröffentlichung.

2. Schreiben Sie ein Plugin. Dieses Verhalten ist ziemlich einzigartig und entspricht nicht wirklich der Art und Weise, wie npm die Versionsverwaltung durchführt. Ich denke, Sie könnten ein Plugin erstellen, um dieses Zeug zu erreichen. Obwohl ich wahrscheinlich ein oder zwei Haken hinzufügen müsste, damit Sie sie verwenden können.

Ein Paket mit einer Version von 0.0.0-development zeigt Folgendes an:

• Die höchste veröffentlichte NPM-Version gilt als "aktuelle Version"
• Die version in package.json sollten niemals geändert werden

Wenn eine neue NPM-Version veröffentlicht werden soll, sollte Auto die "aktuelle Version" mit npm version $(auto version) .

Das Changelog verwendet die "aktuelle Version" von NPM (statt von package.json ).

Wie immer wird für jede NPM-Version ein neues Github-Release erstellt.

Bin ich klar genug?

Die Version in package.json sollte niemals geändert werden

Um neue Versionen in NPM zu veröffentlichen, müssen Sie dies ändern. Die einzige Möglichkeit, die "aktuelle Version" zu erhöhen und die lokale Version niemals zu ändern, wäre:

• auf aktuelle Version (NPM) ändern
• mach die Beule
• ändere es zurück
• aber da wäre das tag der stoß der aktuellen version ???

Ich bin mir ziemlich sicher, dass ich deinen Anwendungsfall verstehe.

A. Sie nicht mehrere Versionen veröffentlichen möchten, während Sie ein Feature über mehrere PRS hinweg entwickeln
B. Sobald eine neue Version veröffentlicht werden soll, möchten Sie, dass alle Änderungen enthalten sind

In meinen Augen bieten wir Ihnen dafür bereits zwei Möglichkeiten:

1. Verwenden Sie onlyPublishWithReleaseLabel . neue Versionen werden erst erstellt, wenn Sie dieses Label hinzufügen. Sie können also jeden PR/Code ohne das Etikett als VERSION-development ansehen

2. Wenn Sie PRs für das große Feature zusammenführen, verwenden Sie skip-release bis Sie für eine Version bereit sind, und führen Sie dann einfach eine PR zusammen. Die neue Version enthält alle übersprungenen PRs. In diesem Fall können Sie das Hinzufügen des Labels skip-release als Zeichen dafür betrachten, dass Ihre Version VERSION-development

Wie unterscheidet sich dies von dem gewünschten Verhalten?

Es scheint mir, sich auf Folgendes zu beschränken: Sie möchten Ihrer Version -development hinzufügen, um Releases zu überspringen und sie zu entfernen, wenn Sie bereit sind, alle Änderungen auf einmal zu veröffentlichen.

Um meinen letzten Satz zu vervollständigen, könnten Sie wahrscheinlich ein Plugin erstellen, das beforeShipit , um das Vorhandensein von -development in der Version zu überprüfen und einen Fehler ausgibt, wenn es vorhanden ist. Dies würde shipit daran hindern, vorwärts zu gehen, bis Sie -development entfernen.

Das einzige Problem, das ich dabei sehe, ist, dass auch der CI-Job fehlschlagen würde.

Interessante Interpretation, aber nicht ganz das, was ich beabsichtigt hatte. 😅

Ich beschreibe im Grunde, wie semantic-release funktioniert.

Ich _sollte_ gesagt haben "Die Version in package.json wird nur vorübergehend geändert, damit npm publish erfolgreich ist" (anstelle von "Die Version in package.json sollte niemals geändert werden"). Alles, was ich wirklich versuche, ist, den Bump-Commit ganz zu vermeiden. :)

Okay, der Zustand, in dem Sie landen würden, ist:

Repo: hat immer nur Version 0.0.0-dev

npm: Hat die ganze Zeit die echte Version (dies wird für alles verwendet)

Korrekt?

In etwa wie

        if (auto.options.skipBumpCommit) {
          // get published version
          // change local version to publish
        } else {
          await execPromise('npm', [
            'version',
            latestBump || version,
            '-m',
            '"Bump version to: %s [skip ci]"'
          ]);
        }

        await setTokenOnCI();

        await execPromise(
          'npm',
          !isPrivate && isScopedPackage
            ? ['publish', '--access', 'public']
            : ['publish']
        );

        if (auto.options.skipBumpCommit) {
          // change local version back to DEV
        } 

        await execPromise('git', [
          'push',
          '--follow-tags',
          '--set-upstream',
          'origin',
          '$branch'
        ]);
      }

Ja, sieht gut aus!

auto v4.0.0 hier kommen wir lol. Sieht so aus, als müsste ich den publish Hook aufteilen. Dies wird ein weiteres Plugin sein

Wenn Sie möchten, können Sie diese Funktion vorerst in Auto integrieren und mit dem Aufteilen des publish Hooks warten, bis ein anderes Plugin es auch benötigt. 😛

Dies sollte nun per Plugin mit #247 (der Semver-Fähigkeit) möglich sein. Die Sache mit der Commit-Nachricht erfordert ein paar Konfigurationsänderungen und bringt Ihnen nicht wirklich viel. Geschlossen, aber offen für PRs!