Auto: Verwenden Sie npm als Versionsquelle der Wahrheit

Ooooh das gefällt mir. Dies könnte jedoch für Monorepos schwierig werden

Da wir --force-publish=* für lerna machen, sollte das kein Problem sein, da alle Pakete eine verlinkte Version haben sollten.

Wenn wir dieses Flag in Zukunft entfernen, müssten wir ... idk

Außerdem führen wir einfach npm version was nur einen Serverstring benötigt. Wir setzen im Moment nirgendwo eine Paketnummer. Es wäre nicht allzu schwer, es selbst einzustellen, aber Monorepos scheinen wieder nicht einfach zu sein

Die meisten Befehle funktionieren auch mit Tags. Wenn die Version also nicht mit Tags versehen wurde, kann dies zu Problemen führen.

https://github.com/azu/can-npm-publish

"Ich bin immer mehr davon überzeugt, dass der "unabhängige" Versionierungsmodus ein Fehler war. Alles, was die Leute dazu bringen, zufällige Pakete in ein einziges Repository zu werfen und sich dann zu beschweren, wenn sie sie gleichzeitig versionieren müssen." ~ vom lerna-Betreuer.

Also --force-publish=* scheint in Ordnung zu sein.

--force-publish und unabhängige Versionierung sind nicht dasselbe.
Standardmäßig veröffentlicht lerna nur dann ein Update für ein Paket, wenn es Änderungen enthält. Mit --force-publish=* zwingen wir lerna, eine Version aller Pakete zu veröffentlichen, auch wenn seit der letzten Veröffentlichung keine Änderungen vorgenommen wurden.

dh Paket A hat Änderungen daran, B nicht. lerna wird nur eine neue Version von A ( B bleibt in der aktuellen Version). Die nächsten Releases A und B haben Änderungen, sie werden beide mit derselben neuen Version veröffentlicht.

Etwas, worüber ich nachgedacht habe (und ich bin mir nicht sicher, ob dies jemals eine Sache ist, die wir unterstützen würden) ist das Potenzial für Veröffentlichungen, die nicht master (oder der Hauptzweig) sind. Bis zu diesem Punkt sind wir immer davon ausgegangen, dass es für Releases nur einen Pfad gibt – und sie sind immer linear (unter Verwendung der latest Version auf npm oder github).

Was passiert, wenn ein früheres Release gepatcht werden muss? (1.x hat einen Fehler, master ist auf 2.x, aber Sie möchten auch 1.x mit einem Fix patchen) Wenn wir von lerna oder pkg abgehen

Wenn wir dies ändern, um etwas außerhalb des Git-Trees zu verwenden, glaube ich nicht, dass wir dieses Verhalten unterstützen könnten, da es auf npm (oder wo immer wir die neueste Version holen) immer nur 1 latest

Das scheint ein gutes Feature zu sein. Die Implementierung kann einige Arbeit erfordern.

Ausführung:

• Wir berechnen version mit der neuesten Version - könnte dies problemlos auf die Paketversion umgestellt werden?
• Die neueste Version auf github könnte ein Problem sein. Ich glaube nicht, dass Sie die "Neueste Version" programmgesteuert festlegen können. Wenn Sie also einen Patch für 1.x veröffentlichen, wird dieser die neueste Version.

Release/Änderungsprotokoll

• getCurrentVersion gibt lastRelease zurück, wenn gt(lastRelease, lastVersion) - also müsste man sich dessen auch bewusst sein

Das bedeutet, dass wir bereits Dinge außerhalb des Git-Trees verwenden, oder?

Wir müssen uns auf LatestRelease verlassen, um sicherzustellen, dass ein Git-Tag damit verknüpft ist. Daher ist ein Wechsel keine Option, da wir nicht sicher sein können, ob die neueste npm-Version ein Tag hat (wie in der Sache, die in diesem Problem beschrieben wird). .

Ich denke, dass wir wahrscheinlich ein neues Flag brauchen würden, das vom letzten git-Tag abweicht. --from-git

Damit würde wohl der Release-Befehl funktionieren. Wir müssten klären, wie das Changelog aussieht.

das --from-git Flag könnte auch die Suche nach NPM überschreiben. Ich denke, das bedeutet, dass wir #173 zusammenführen können