kein Release für die neueste(n) Version(en)?
IngoWinter opened this issue · 13 comments
Das letzte Release hier auf Github ist die 1.4.3, im Installer gibt es aber schon die 2.0.2. Geile Hillfepage übrigens 👍
Ägypten? Das hier in Github ist dieselbe Version wie im Installer.
Oh manno, der kryptische Github-Overhead nervt mich ganz gewaltig. Was soll denn jetzt hier wieder passieren? Ich verstehe die Doku nicht wirklich: wenn alles beisammen ist (also alle PR, die zum neuen Release gehören, gemerged sind) drafte ich zusätzlich ein neues Release und publiziere es. Oder wie, oder so, oder anders?
Oder wie, oder so, oder anders?
Informationen dazu findest du hier https://github.com/FriendsOfREDAXO/friendsofredaxo.github.io#ein-release-eines-addons-erstellen
Der Text bei FOR ist sehr kurz. Was hier gewollt wird: Auf den letzten Commit, der zum Release führt — in der Regel sollte er die Version in der package.yml erhöhen —, setzt du einen Git-Tag, der dieser neuen Version entspricht, z. B. 2.0.2. Wenn du nun pushst, wir dieser Tag mitgepusht (falls du einen Git-Client wie Sourcetree verwendest, musst du die Option evtl. noch per Checkbox »Push tags« oder so anhakeln). Jedenfalls, Tagging ist eine native Git-Funktion, die erstmal nichts mit GitHub zu tun hat.
Der Tag ist wie ein Lesezeichen. Er besagt nicht mehr, als dass du den Stand deines Repos an genau dieser Stelle markieren möchtest. Benutzer können mit dem Tag arbeiten und sich beispielsweise genau diesen Stand exportieren.
Jetzt kommt GitHub ins Spiel: Es erkennt Tags und schlägt dir vor, daraus Releases zu erstellen. Dazu wählst du den gewünschten Tag aus und ergänzt eine Beschreibung. Danach steht das Release bereit, und GitHub bietet automatisch eine URL dafür an, führt es in der Release-Übersicht auf und stellt ein Zip bereit.
Dieses Zip wiederum solltest du dann 1:1 im REDAXO-Installer veröffentlichen. GitHub ist die eine wichtige Quelle, an der die gesamte Entwicklung passieren sollte. Erst danach fließen Projekte in den REDAXO-Installer. (Was nicht bei GitHub ist, existiert nicht.)
@tbaddade Aktuell wenig Muße, aber irgendwann — im Winter? — gerne, dann so richtig vollständig und mit Screenshots.
Danke für die Infos. Ich schau mal, ob ich mir Urlaub nehme und ne längere Git-Schulung mache. Im Idealfall (für mich, nicht für den RdW) warte ich dann mal auf die Erläuterung im Winter :-)
Heißt im Worst Case: falls ich es bis dahin nicht verstanden habe gibt es keine neuen Releases. , Nee im Ernst, ich frag mich dann durch.
@christophboecker ich hab noch nie einen Git Tag gesetzt sondern mach immer direkt ein Release fertig. Einfach bevor du das Dingen in den Installer packst das gleiche hier unter Release machen, fertig:
Was Ingo sagt. Allerdings setzt GitHub dann den Tag in dem Moment, wo man auf den Releaseknopf drückt, und falls in der Zwischenzeit jemand was committet hat, landet das mit im Release. Wenn man also mehr Kontrolle möchte, sollte man den Tag vorher manuell selbst setzen. In üblichen Git-Clients wie Sourcetree und Tower ist das nur ein Rechtsklick auf den passenden Commit, und dann im Kontextmenü sowas wie »Add Tag«. Done.
So! V2.1 im Installer und als Release. Causa finita.