Auto: Hotfixes - Support-Patches für alte Minderjährige und Patches

@hipstersmoothie
Haben Sie Details, wie dies umgesetzt werden würde / wie es in der Praxis aussehen würde?

Außerdem bin ich mir nicht sicher, ob ich verstehe, was merge into a tag bedeutet ... könnten Sie das möglicherweise klären? Mein Verständnis war, dass man eine PR nur mit einer Filiale als Ziel erstellen konnte.

Nein, über das Problem habe ich mir noch nicht allzu viele Gedanken gemacht.

Außerdem bin ich mir nicht sicher, ob ich verstehe, was das Zusammenführen in ein Tag bedeutet

Die Benutzeroberfläche hat mich zu der Annahme veranlasst, dass Sie möglicherweise in ein Tag zusammenführen können, aber bei weiterer Überprüfung scheint dies nicht möglich zu sein. Wenn wir könnten, wäre dies jedoch möglich.

Wenn ich mich ein wenig erinnere, denke ich, dass ich Folgendes dachte:

1. Tag 1.2.3 existiert, aktuelle Version ist 2.0
2. PR wird in Tag 1.2.3 gemacht, produziert 1.2.3-0 (die 0 ist der Build-Teil von semver)

ok, die Verwendung von build part von semver macht definitiv Sinn. 👍

Wenn es nicht möglich ist, eine PR direkt zu einem Tag zu machen, dann kann dieser Ablauf erfordern, dass Repo-Besitzer einen Zweig aus einem Tag im Upstream-Zweig erstellen (Zielzweig für PR). Es wäre etwas ärgerlich, aber ich bin mir nicht sicher, ob es eine bessere Alternative geben würde. Darüber hinaus sind diese Arten von Veröffentlichungen wahrscheinlich nicht üblich, daher wäre dies möglicherweise in Ordnung.

Ein ähnlicher Ansatz zur alten großen Unterstützung ( versionBranches ) könnte verwendet werden, wo ein Branch-Präfix in der Konfiguration angegeben werden könnte. Es scheint, dass diese Funktion eher auf Hotfix-Versionen ausgerichtet ist, daher ist es möglicherweise sinnvoll, die Konfiguration von der alten großen Unterstützung zu trennen. Was denken Sie?

Ein Beispielablauf könnte so aussehen:

• Benutzer gibt in der Auto-Konfiguration an, mit Build-IDs für Branches mit dem Präfix hotfix- build zu bauen
• vorhandenes Commit-Log
  <ul> <li>(tag: v2.0.0) (master)<br /> |</li> <li>(tag: v1.2.0)<br /> |</li> <li>(tag: v1.1.0)<br /> |</li> <li>(tag: v1.0.0)<br />

Ein ähnlicher Ansatz zur alten Hauptunterstützung (versionBranches) könnte verwendet werden, wo ein Branch-Präfix in der Konfiguration angegeben werden könnte.

Ich mag die Idee, aber in der Praxis glaube ich nicht, dass es so viel Spaß machen würde. Da auto eine Menge veröffentlicht, würden Sie am Ende eine verrückte Anzahl von Zweigen erhalten.

Wenn es nicht möglich ist, eine PR direkt zu einem Tag zu machen, dann kann dieser Ablauf erfordern, dass Repo-Besitzer einen Zweig aus einem Tag im Upstream-Zweig erstellen (Zielzweig für PR). Es wäre etwas ärgerlich, aber ich bin mir nicht sicher, ob es eine bessere Alternative geben würde. Darüber hinaus sind diese Arten von Veröffentlichungen wahrscheinlich nicht üblich, daher wäre dies möglicherweise in Ordnung.

Ich stimme zu, dass diese Art der Veröffentlichung nicht der Norm entspricht. das macht die automatisierte Branch-Erstellung weniger nützlich. Sie würden viel Lärm (mehr Zweige) bekommen, ohne sie allzu oft zu verwenden, wenn überhaupt.

Was Ihren oben vorgeschlagenen Ablauf angeht, scheint das gut zu funktionieren. Es ist bedauerlich, dass wir PRs jedoch nicht in Tags umwandeln können! würde diesen Arbeitsablauf erheblich vereinfachen.

Wenn man darüber nachdenkt, benötigt diese Funktion wahrscheinlich ein paar Dinge in auto , um vollständig ausgearbeitet zu werden:

1. Neuer Befehl auto hotfix : Beim Ausführen wird das Projekt mit einer neuen Hotfix-Version basierend auf dem neuesten Tag im Zweig veröffentlicht
2. Neue Funktionalität für auto shipit : Erkennen, ob wir uns in einem hotfixBranch und auto hotfix ausführen

Wie auto hotfix funktionieren sollte, könnte entweder so aussehen:

1. the way of next or canary => Neuer Hook, der es dem Plugin ermöglicht zu kontrollieren, wie Hotfix veröffentlicht wird, ob es überhaupt unterstützt wird
2. Verwenden Sie die Hooks version und publish und machen Sie sie in der Lage, build Semver freizugeben

Von den beiden Optionen tendiere ich eher zu 1 da das Aufrufen der Hooks version und pubish auf eine neue Art und Weise als Breaking Change angesehen werden könnte. Der Nachteil dabei ist, dass einige der Hooks nicht afterVersion heißen, wodurch einige Plugins nicht funktionieren. Dies ist derzeit jedoch sowohl für canary als auch für next ein Problem. da sie diesen Haken auch nicht nennen. Also etwas, worüber man sich nicht sofort Sorgen machen muss.

Sind Sie daran interessiert, dies hinzuzufügen?

Ich mag die Idee, aber in der Praxis glaube ich nicht, dass es so viel Spaß machen würde. Da automatisch viele Veröffentlichungen veröffentlicht werden, erhalten Sie am Ende eine verrückte Anzahl von Zweigen.

Hoppla, bedeutete, dass es in Bezug auf eine Branch-Präfix-Konfiguration der alten großen Unterstützung ähnlich war. Stimme auf jeden Fall zu, dass das automatische Erstellen von Verzweigungen zu viel Lärm verursachen würde, insbesondere bei häufigem Loslassen, 😆

Wenn man darüber nachdenkt, benötigt diese Funktion wahrscheinlich ein paar Dinge in Auto, um vollständig auszugestalten:

1. Neuer Befehl Auto-Hotfix: Beim Ausführen wird das Projekt mit einer neuen Hotfix-Version basierend auf dem neuesten Tag im Zweig veröffentlicht
2. Neue Funktionalität für Auto Shipit: Erkennen, ob wir uns in einem HotfixBranch befinden und Auto Hotfix ausführen

ja. Ich denke, das würde die erforderlichen Änderungen weitgehend kapseln.

Wie der automatische Hotfix funktionieren sollte, könnte entweder gehen:

1. the way of next or canary => Neuer Hook, mit dem das Plugin steuern kann, wie Hotfixes veröffentlicht werden, ob es überhaupt unterstützt wird
2. die Version wiederverwenden und Hooks veröffentlichen und sie in die Lage versetzen, Build-Semver freizugeben

Von den beiden Optionen tendiere ich eher zu 1, da das Aufrufen der Versions- und Publish-Hooks auf eine neue Art und Weise als bahnbrechende Änderung angesehen werden könnte. Der Nachteil dabei ist, dass einige der Hooks nicht afterVersion aufgerufen werden, wodurch einige Plugins nicht funktionieren. Dies ist derzeit jedoch ein Problem für Canary und Next. da sie diesen Haken auch nicht nennen. Also etwas, worüber man sich nicht sofort Sorgen machen muss.

Hohes Niveau, ich denke, 1 macht auch Sinn. Ich müsste den Code durchgehen, um besser zu verstehen, welche Hooks für welchen Befehl aufgerufen werden, aber wenn next , canary , & hotfix alle ähnlichen Mustern folgen, dann wären eventuelle Schmerzpunkte später wahrscheinlich leichter zu lösen.

Sind Sie daran interessiert, dies hinzuzufügen?

Klar 👍, würde ich gerne machen.
Ich werde wahrscheinlich erst nächste Woche einen Blick auf die Implementierung dafür werfen können, aber ich denke, das ist in Ordnung, da diese Ausgabe seit März nicht mehr aktualisiert wurde.

Fantastisch! Keine geplante Arbeit an diesem, also bist du alles

FWIW - Ich wollte versuchen, dies als Plugin zu konstruieren, indem ich genau das tue, was Sie als minderwertig angesehen haben - einen version-MAJOR-MINOR Zweig zu erstellen. Es fühlt sich bei unserem aktuellen Prozess TBH nicht nach zu viel Lärm an. Wir erstellen bereits Zweige für jede Release-Linie.

Ein Großteil von versionBranches ist derzeit dieses Plugin :

    this.hooks.beforeCommitChangelog.tapPromise(
      "Old Version Branches",
      async ({ bump }) => {
        if (bump === SEMVER.major && this.config?.versionBranches) {
          const branch = `${this.config.versionBranches}${major(
            await this.hooks.getPreviousVersion.promise()
          )}`;

          await execPromise("git", [
            "branch",
            await this.git?.getLatestTagInBranch(),
          ]);
          await execPromise("git", ["push", this.remote, branch]);
        }
      }
    );

Es sieht trivial aus, Unterstützung für SEMVER.minor hinzuzufügen, aber ich gebe zu, dass ich nicht weiß, was andere Teile von Auto möglicherweise ändern müssen.

Das ist ein Teil dessen, was für alte Versionen passiert, aber dann muss diese Prüfung in shipit auch bestehen

https://github.com/intuit/auto/blob/f37945b45b7fef6ffdb00ffa0250de449e02b883/packages/core/src/auto.ts#L1442

Was dann hierher geht und im Grunde nur überschreibt, wo die Berechnung der Freigabe beginnen soll

https://github.com/intuit/auto/blob/f37945b45b7fef6ffdb00ffa0250de449e02b883/packages/core/src/auto.ts#L1509

Die einzige Überlegung, die wir bei altem Minor/Patch und nicht bei Major anstellen müssen, ist die mögliche Versionsabweichung. Bei Minderjährigen ist es wahrscheinlich weniger problematisch

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.1.1)
|
|  *  (tag: v1.1.2) <- Need to add logic to find an available tag 
| /
*  (tag: v1.1.0) (hotfix-feature)
|
*  (tag: v1.0.0)

Vielleicht wird der Befehl hotfix also nicht benötigt. Stattdessen könnte es einfach versuchen, eine eindeutige Versionsnummer zu verwenden. Es sollte jedoch möglicherweise eine Validierung erforderlich sein.

Regeln :

1. Major kann nicht auf einem alten Minor-/Patch-Release-Zweig veröffentlicht werden (erforderlich)
2. kann Minor nicht auf einem alten Patch-Release-Zweig veröffentlichen (vielleicht unnötig?)

@hipstersmoothie
Wissen Sie, wie das Standardverhalten jetzt ist, wenn Sie ein CI-Setup haben, um auf einem älteren Tag aufzubauen, bei dem das nächste Tag nicht verfügbar ist?

Ich vermute, dass es einen Fehler geben würde, obwohl ich nicht sicher bin, wo dieser Fehler auftreten würde (vielleicht beim Tag-Push?).

dh:

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.1.1)
|
|  *   <- what is current behavior if I try to release this commit
| /
*  (tag: v1.1.0) 
|
*  (tag: v1.0.0)

Außerhalb der Durchsetzung der von @hipstersmoothie angegebenen Regeln try to unique version number . Für das Beispiel, das @hipstersmoothie gegeben hat, würde v1.1.2 von anderen als Patch-Release von v1.1.1 , aber da die Entwicklung nicht linear verlief, kann dies nicht garantiert werden. Möglicherweise gibt es sogar eine rückwärts inkompatible Änderung von v1.1.1 zu v1.1.2 da es wahrscheinlich ist, dass v1.1.2 die Änderungen von v1.1.1 . Dies könnte sich verschlimmern und noch verwirrender werden, wenn die nächste eindeutige Version eine größere Entfernung von v1.1.0 (dh: Was ist, wenn die nächste eindeutige Version v1.1.100 ?)

Die Verwendung des Build-Metadaten-Teils von Semver würde diese Verwirrung begrenzen, da er gemäß den Semver-Spezifikationen bei der Berechnung der Versionspriorität ignoriert wird. Wenn die Build-Metadatennummer inkrementiert wird, könnte vielleicht Commit sha anstelle einer inkrementierenden Nummer verwendet werden.

Im Allgemeinen ist die Softwareentwicklung nicht unbedingt linear, sodass Sie sich nicht sicher sind, ob es die beste Implementierung gibt.

Wenn wir verallgemeinern wollen, könnten wir vielleicht eine Art Konfiguration oder Hook haben, um die Strategie für oben unabhängig vom Branch anzugeben (oder Branch könnte ein Parameter zum Hooken sein).
Auf diese Weise könnten unterschiedliche Implementierungen über Plugins verwendet werden.

Wissen Sie, wie das Standardverhalten jetzt ist, wenn Sie ein CI-Setup haben, um auf einem älteren Tag aufzubauen, bei dem das nächste Tag nicht verfügbar ist?

Normalerweise werden Tags nicht erstellt, weil der Commit [skip ci] in der Nachricht enthält

Dies könnte sich verschlimmern und verwirren, wenn die nächste einzigartige Version einen größeren Abstand zu v1.1.0 hat

Dies ist ein großartiger Punkt. Macht den Build-Metadaten-Teil der Version definitiv zur richtigen Strategie.

Wenn wir verallgemeinern wollen, könnten wir vielleicht eine Art Konfiguration oder Hook haben, um die Strategie für oben unabhängig vom Branch anzugeben (oder Branch könnte ein Parameter zum Hooken sein).
Auf diese Weise könnten unterschiedliche Implementierungen über Plugins verwendet werden.

Ihr Beitrag hat mich ziemlich überzeugt, dass das Finden eines einzigartigen Tags ein verwirrendes Schema ist und wir wahrscheinlich nicht sollten.

Vielleicht könnte es funktionieren, wenn wir eine Mischung machen. Das Patchen und Old Minor sollte einfach sein. Es könnte genauso funktionieren wie oldVersionBranches für Majors:

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.2.0)
|
|  *  (tag: v1.1.5) <- Can merge patched into old minor branch, maybe error when PR has `minor`
| /
*  (tag: v1.1.4) <- branch: version-1.1
|
*  (tag: v1.0.0)

Dann müssen wir nur noch den Teil der Build-Metadaten zum Patchen von Patches ausführen.

Gibt es mit den zusammengeführten Optionen from und useVerion eine integrierte Möglichkeit, einen Hotfix durchzuführen? Ich musste heute nur einen machen und habe mich dafür entschieden, es mühsam manuell zu machen.

Für den Kontext ist mein Projekt am 7.7. Ein Hauptverbraucher unseres Projekts veröffentlicht derzeit eine Version, die auf 7.5 ist, ein Problem gefunden hat und 7.5.1 benötigt, damit sie nicht alles mitten in der Veröffentlichung erneut überprüfen müssen. Nicht optimal, kommt aber gelegentlich vor.

Dies ist meines Wissens immer noch nicht ohne manuelle Eingriffe möglich. Ich denke, jemand hier bei Intuit plant, dies irgendwann hinzuzufügen. Ich stimme zu, dass dies eine schmerzlich fehlende Funktion in Auto ist

Toll zu hören! Danke 🙏

Wir (ich und @10hendersonm) haben dafür eine Lösung entwickelt, aber es ist ziemlich
beteiligt. Es verwendet jedoch ausschließlich Auto und Plugins!

Wir haben gerade 7.2.1, 8.1.1 und 8.2.2 unseres Projekts mit Hilfe von PRs gefixt
(sehr vorsichtig).

Wir könnten prüfen, wie wir dies teilen können, wenn die Leute interessiert sind.

Am Do, 14. Januar 2021, 19:27 Uhr schrieb Matt Felten [email protected] :

Toll zu hören! Danke 🙏

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/intuit/auto/issues/1054#issuecomment-760583830 oder
Abmelden
https://github.com/notifications/unsubscribe-auth/AACI3Q6RKDONYJVH6UWUPFLSZ6KZNANCNFSM4LFJ4ULQ
.

Ich wäre sehr interessiert!

Hallo alle! Ich bin daran interessiert, dazu beizutragen. Mein Vorschlag ist folgender:

1. Im Allgemeinen versucht auto , alle version-* Zweige zu respektieren. Zum Beispiel erzeugt ein Patch-Merge von einem beliebigen Branch in version-1.1.4 eine Version der Version 1.1.5 . Wenn diese Version bereits erstellt wurde, schlägt entweder die NPM-Version oder das Git-Tag fehl, aber dies ist ein normaler und erwarteter Fehlerfall
2. Wir können aktualisieren versionBranches akzeptieren "major" | "minor" | "patch" , die Zweige Potential Hotfix generieren , basierend auf , was Sie angeben. Auf diese Weise können Sie den Kompromiss wählen, ob Sie manuell einen version-* Zweig erstellen müssen und am Ende viel zu viele Zweige haben, die verwaltet werden müssen, wenn Sie keine Korrekturen benötigen

Die Gedanken?

aber das ist ein normaler und erwarteter Fehlerfall\

Ich würde immer noch erwarten, dass dies eine Art von Version erstellt. Ich hatte vor kurzem einen Fall, in dem ich einen Hotfix von einem bestimmten Commit veröffentlichen wollte, um nichts anderes einzufügen. Ich denke, in diesem Fall könnten wir den Build-Teil von semver aus der obigen Konversation verwenden.

Wir können versionBranches aktualisieren, um "major" zu akzeptieren | "geringfügig" | "flicken"

Die aktuelle Konfiguration kann entweder true oder eine Zeichenfolge sein, die den Hauptzweigen vorangestellt wird. Ich denke, die neue Konfiguration müsste ungefähr so ​​aussehen

{
  "versionBranches": {
      "branchPrefix": "version-",
      "types": ["major", "minor"] // defaults to just major   
   }
}

Die letzte zu beantwortende Frage ist immer noch Hotfix-Hook oder Aufruf von version+publish-Hooks , wenn wir uns den Code für die aktuelle Implementierung des alten Versionszweigs ansehen.

@lshadler Wir müssen uns für eine Weile darauf

@bmuenzenmeyer Kannst du einen Überblick über deinen Ansatz geben?

Je mehr ich über die Implementierung nachdenke, desto mehr denke ich, dass dies v11 und mehr Kontext zur Versions- und Veröffentlichungsbefehle erforderlich machen wird.

Für alte Versionen benötigen wir die vollständige neueste Pipeline, um mit changelog, afterVersion und allen oder ihren Hooks, die während einer neuesten Version aufgerufen werden, zu laufen.

Wir sollten wahrscheinlich machen, dass die nächsten Releases die gleiche Version haben, nachdem die Version nach dem Publish-Flow neuesten veröffentlicht wurde. Das kann auch ein Teil von v11 sein. Es sollte dem neuesten Workflow entsprechen, damit Sie eine ähnliche Automatisierung hinzufügen können.

Der Canary-Workflow kann gleich bleiben, da für einen Canary nichts festgelegt wird und Sie bereits auf den Canary-Hook tippen können, um mehr zu tun.

Hallo zusammen, bei der Verrücktheit des letzten Jahres ist mir dieses Thema leider entgangen.

In Bezug auf die verschiedenen Ansätze denke ich, dass es hilfreich sein kann, die verschiedenen Anwendungsfälle zu berücksichtigen, für die diese Funktionen gelöst werden. Meiner Meinung nach sehe ich 2 Anwendungsfälle:

• (1) langfristige Unterstützung für einen alten Zweig (zB: alte Hauptversion)
• (2) kurzfristiger Support für eine bestimmte Version (zB: Hotfix)

Basierend auf diesem Gespräch halte ich es für sinnvoll, für jeden dieser Anwendungsfälle unterschiedliche Ansätze zu haben.

(1) Für die langfristige Unterstützung eines Branch/Release-Tracks denke ich, dass versionBranches in der Lage sein sollte, zu lösen. Wenn Sie dieses Verhalten für kleinere Versionen erweitern möchten (wie einige oben erwähnt haben), könnte dies eine Verbesserung dieser Funktionalität sein.

(2) Für kurzfristigen Support / Hotfix, basierend auf den obigen Threads, sollte es einen Standardweg für Benutzer geben, immer den Build-Teil von Semver zu verwenden, um eine Hotfix-Version zu generieren. Dies ermöglicht ein konsistentes Verhalten für Codebesitzer und vermeidet einige komplizierte Eckfallszenarien. Für diesen Fall denke ich, dass ein neuer Hotfix-Befehl und ein neuer Hook verwendet werden könnten. Dies könnte eine deutliche Verbesserung sein. Im Allgemeinen sollte dieser Anwendungsfall relativ selten sein, da Verbraucher ermutigt werden sollten, nach Möglichkeit die neueste Versionierung zu verwenden.

edit _(Für den kurzfristigen Anwendungsfall könnte die versionBranches Konfiguration möglicherweise erweitert werden, um einen Parameter / Toggle / Flag zuzulassen, der angibt, ob die Semver-Labels für die version- Zweige berücksichtigt oder immer verwendet werden sollen den Build-Teil von semver und ignoriere alle Labels für diese Branches)_

Gibt es noch andere Anwendungsfälle als diese 2, die in Betracht gezogen werden sollten?

Sollten unterschiedliche Ansätze für unterschiedliche Anwendungsfälle in Betracht gezogen werden?

(Außerdem kann ich bei einigen dieser Änderungen immer noch helfen, möchte aber definitiv niemanden daran hindern, Änderungen dafür zu übernehmen)

auch ein tangentialer Gedanke für Verzweigungsmuster:

auto generiert ein Git-Tag (Release) für Releases. Dies bedeutet, dass eine gültige git ref an github gepusht wird. Für den Anwendungsfall der kurzfristigen Unterstützung (zB: kurzlebiger Zweig / Hotfix-Zweig) bedeutet dies, dass ein Benutzer den kurzlebigen Zweig löschen kann, nachdem ein Release / Git-Tag gepusht wurde.

• einen Master-Zweig mit folgenden Tags gegeben
  <ul> <li>(tag: v1.3.0) (master)<br /> | </li> <li>(tag: v1.2.3)<br />

Bei kurzlebigen Verzweigungen kann es sinnvoll sein, das obige Verzweigungsmuster beim Hinzufügen von Features zu dokumentieren. Ich habe persönlich festgestellt, dass viele nicht wissen, dass Sie den Branch löschen können und trotzdem auf den neuen Commit verweisen, was verschiedenen Projekten helfen kann, das Durcheinander von kurzlebigen Branches zu reduzieren.

Ich habe vor kurzem mit Code herumgespielt, um den Build-Teil von Semver zum Erstellen von Builds zu verwenden. Dabei stieß ich auf den Anwendungsfall, bei dem die neueste Github-Version nicht unbedingt die neueste/höchste semantische Version war.

Im hier erwähnten Beispiel: https://github.com/intuit/auto/issues/1054#issuecomment -780286683 würde die neueste github-Version als v1.2.3+1 angezeigt, da sie zeitlich nach der höchsten erstellt wurde version semantische version: v1.3.0 .

Da viele Stellen im Code auf getLatestRelease verweisen, kann dies zu unterschiedlichem Verhalten führen, wenn die Pipeline den Parameter from nicht explizit festlegt. dh:

• Was ist in den Versionshinweisen enthalten?
• als was die vorherige Version berechnet wird
• potenziell unterbrechende Funktionalität, wenn die neueste Github-Version nicht über HEAD-Commit erreichbar ist

Ich habe es nicht getestet, aber ich glaube, diese Arten von Szenarien wären auch über das vorhandene versionBranches Verhalten erreichbar. Ich glaube, dies hängt mit dem Kommentar zusammen, welche Flows Git-Tags / Github-Releases generieren sollten:

Die letzte zu beantwortende Frage ist immer noch Hotfix-Hook oder Aufruf von version+publish-Hooks , wenn wir uns den Code für die aktuelle Implementierung des alten Versionszweigs ansehen.

In Bezug auf die Lösung kann dieses Problem wahrscheinlich unabhängig vom Hook-Refactoring gelöst werden, indem die Logik getLatestRelease entweder durch Folgendes ersetzt wird:

• (1) Github-Releases mit listReleases abrufen und dann sortieren, um die höchste erreichbare Release-Version (keine Vorabversion oder Build-Teile) zu finden
• (2) oder holen Sie sich Git-Tags und sortieren Sie sie, um die erreichbare höchste Release-Version (keine Vorabversion oder Build-Teile) zu finden

Der Unterschied hier wäre, ob auto Github-Releases oder Git-Tags als Quelle der Wahrheit ansieht, was mit der Diskussion https://github.com/intuit/auto/discussions/1867#discussioncomment -684192 zusammenhängt.

Ich würde mich anfangs zu (2) neigen, da

• (a) Wir sind letztendlich nach dem git ref (tag) und nicht den anderen Elementen des github-Release
• (b) es würde die Anzahl der Netzanrufe reduzieren

@hipstersmoothie ,
Wenn wir die getLatestRelease Logik ändern müssen, was denken Sie über (1) die Verwendung von github-Releases vs. (2) die Verwendung von git-Tags vs. (3) etwas anderes?

Ja, damit Multi Package Auto funktioniert, müssen alle neuesten GitHub-Release-Zeugs in nur Tags umgestaltet werden. 2 ist definitiv die Option, um diese Arbeit zu erledigen.