kein Release für die neueste(n) Version(en)? about focuspoint HOT 13 CLOSED

@tbaddade Aktuell wenig Muße, aber irgendwann — im Winter? — gerne, dann so richtig vollständig und mit Screenshots.

from focuspoint.

So! V2.1 im Installer und als Release. Causa finita.

from focuspoint.

Ägypten? Das hier in Github ist dieselbe Version wie im Installer.

from focuspoint.

@IngoWinter meint das hier https://github.com/FriendsOfREDAXO/focuspoint/releases

from focuspoint.

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?

from focuspoint.

Oder wie, oder so, oder anders?

Informationen dazu findest du hier https://github.com/FriendsOfREDAXO/friendsofredaxo.github.io#ein-release-eines-addons-erstellen

from focuspoint.

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.)

from focuspoint.

@schuer Schön erklärt. Magst du das mit im Friends Repo aufnehmen?

from focuspoint.

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.

from focuspoint.

https://de.wikipedia.org/wiki/RDW ???

from focuspoint.

@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:

from focuspoint.

from focuspoint.

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.

from focuspoint.