[osdteletext] 2.0.0 released

Quote from pbrb

https://github.com/pbiering/vd…ext/tree/2.0.2-regression

-> leider noch kein Feedback bekommen

Gestern, bei einem kurzen Test, gab es keine Probleme, im Setup ist alles übersetzt. Danke!

Quote from pbrb

Release erstellt

Die beiden GIT Stände sind aber nicht per Commit auf den Stand 2.0.2.

Hab gerade beide GIT Stände gebaut vom Plugin aber keinen Tag....

Quote from pbrb

-> leider noch kein Feedback bekommen

Wenn man potentiellen Testern erzählt, dass sie das falsche Repository benutzen, und sie mit einer chaotischen Branch-and-Merge-Strategie (ok, vielleicht habe nur _ich_ das System nicht verstanden) ohne Tags alleine laesst, dann laeuft es eben darauf hinaus.

Und ansonsten, Feedback innerhalb von 11 Stunden wuerde ich jetzt ohne spezielle Absprache nicht unbedingt voraussetzen.

Quote from pbrb

Release erstellt

Releases v2.0.1 und v2.0.2 sind identisch, was vermutlich nicht so gedacht ist.

Auch sind im master immer noch die tr() statt trNOOP() fuer st_modes drin. Auch das erscheint mir nicht sinnvoll.

Und nein, _dieses_ Release v2.0.2 funktioniert immer noch nicht, meldet sich ja auch 2.0.1.

Gruss,

S:oren

Es gibt ja genug Plugins wo man aus einem Repo sowohl die Tags und die Commits raus bauen kann, wie man will. Bei diesem Plugin hier ist halt das "gewurschtel" zwischen den beiden "Adressen" sehr groß wie bereits beschrieben

Ein Entwickler-Repo halte ich auch fuer eine sehr gute Idee. Auch gerne mit verschiedenen aktiven Entwicklungs-/Topic-/Test-/Was-auch immer-Branches (neben dem master).

Bitte einen Branch fuer jede Entwicklungslinie, diese Branches immer basierend auf einem getaggten Release, und nur an einer Sache gearbeitet in jedem Branch. Bei auftretenden Problemen gerne mit auch mal mit einem topic-v2-Branch (basierend auf dem selben Tag wie topic), wo mit git rebase (fixup/squash) die Probleme in den Commits des topic(-v1)-Branches gefixt werden und so spaeter noch die wirklich letztendlich sinnvolle Entwicklung nachvollzogen werden kann. Die Commits gerne mit einer sinnvollen Beschreibung, _warum_ man etwas so gemacht hat (was geht ja aus dem Code hervor). Beim Beschreiben merkt meist man selbst recht schnell, ob das so eigentlich wirklich Sinn ergibt.

Wenn dann ein Feature fertig und getestet ist, dann wird das in in den master gemerged (nicht umgekehrt). Ich bin ja eher ein Freund von rebase, wenn sowieso nur ein Entwickler daran arbeitet. Aber auch jeweils ein expliziter Merge-Commit waere ein sinnvolle Strategie, was dann fuer Einheitlichkeit bei Merges von externen Topic-Branches aus Repositories anderer Entwickler sorgt. Dann koennen anschliessend die lokalen topic(-vx)-Branches wieder geloescht werden.

Nach einem oder mehreren Topic-Merges wird dann _im master_ eine neue Version erzeugt und getaggt. Und dieser getaggte master-Branch aus dem Entwickler-Repo wird dann unveraendert in das Haupt-Repo gepusht (nicht gemerged), so dass die git-IDs in beiden Repos fuer Releases identisch sind.

Das halte ich fuer eine sinnvolle git-Entwicklungsstrategie, kann es hier natuerlich nur so vorschlagen. Sicherlich ist das auch nicht die einzig moegliche Strategie, z.B. git-flow sieht noch kompliziertere Regeln vor. Das halte ich hier fuer uebertrieben, ist nur meine persoenliche Meinung.

Letztendlich braucht man auch nicht unbedingt ein zweites Entwickler-Repo, wenn man direkt im Haupt-Repo arbeitet (und sich daran haelt, dort niemals im master zu entwickeln). Dann braucht man auch kein lokales Repo mit mehreren Remotes (was an sich kein Problem waere, ich habe z.B. auch ein lokales Repo mit 4 Remotes). Hier fuer osdteletext funktioniert das nur nicht (gut), weil eben die Releases im Entwicklungs- und Haupt-Repo nicht die selben Commit-IDs haben.

Mal so als Anregung,

S:oren

Quote from pbrb

Richtige Handhabung von git ist wohl nicht so trivial...und meine Kenntnisse darin nicht die besten....ich gebe gerne die Leitung vom Haupt-Repo wieder ab

Schade. Waere ja eine gute Gelegenheit zu lernen, wie es besser gemacht werden kann.

Gruss,

S:oren

Quote from pbrb

So, mein 2.1.0 branch ist nun im offiziellen "milestone-2.1.0" Branch reinmigriert

Naja, meldet sich wieder mit 2.0.2_38_gb2f5e02 als Version weil kein Tag vorhanden ist. Nach welcher Grundlage werden die großen Sprünge in kurzer Zeit der jeweiligen Versionen hier eigentlich geändert?

Soweit weg kannst Du ja nicht sein, von einer Funktionsweise im Umgang mit dem GIT damit das Pushen und Taggen passt. Wenn es wo klemmt wird dir sicher hier geholfen und eine Frage ist ebenfalls kein Beinbruch

Du müsstest auch nicht die Version als "beta" umschreiben, es reicht doch zu jedem Tag (also neues Release) die Version anzupassen. Die Stände dazwischen sind "Entwicklungsstände", das machen doch alle anderen auch so. In der obigen Zeile wäre es dann der 38igste Commit nach dem Release 2.0.2

Wenn man das Repo von markad mal nimmt als Beispiel, da ist der Master Zweig und wenn erweitert wird der Zweig V02 der wo entwickelt wird, wenn es passt kommt es nach Master rüber gemerged.

Hat jetzt nichts mit Zoo oder so zu tun, ist schlicht, einfach, funktionell. Kann auch sein dass du es nicht so machen willst sondern einen eigenen Weg hast, dann eben diesen

Quote from utiltiy

ist schlicht, einfach, funktionell.

Danke für die Blumen, genau das war das Ziel.

Quote from utiltiy

Naja, meldet sich wieder mit 2.0.2_38_gb2f5e02 als Version weil kein Tag vorhanden ist.

Das finde ich genau richtig so. Ist ein separater Entwicklungsbranch, und der hat noch keine Versionsnummer oder Tag (mehr s.u.).

Quote from pbrb

...wenn das immer noch nicht gefällt, dann mach ich nur noch PRs und um das Hauptrepo und die Einsortierung kund Taggen ann sich jemand anders kümmern...

Du bist Maintainer, kannst also machen, was Du willst.

Ich hatte beschrieben, wie ich es handhaben wuerde, wenn ich Maintainer waere. Diese Regeln sind natuerlich nicht die einzig sinnvollen, haben sich aber in anderen großen Community-Projekten (linux, u-boot) bewaehrt. Ob man sich hier darauf einigen moechte, wurde ja noch nicht mal diskutiert.

Das Einhalten solcher Regeln erfordert Disziplin, ermoeglicht aber auch eine einfachere Zusammenarbeit und ergibt eine bessere Qualitaet und Wartbarkeit des Codes. Der Branch milestone-2.1.0 erfuellt wieder quasi alle meine Regeln nicht (muss er auch nicht, ich bin ja nicht der Maintainer). Aber so weiss ich weder, was ich testen sollte (welche Features/Fixes,...), noch kann ich irgendwas reviewen (was ist der Grund fuer die Aenderungen, gibt es bessere Implementierungsalternativen), noch ist klar, in welcher Beziehung dieser Branch zum aktuellen master steht, und was der aktuelle Stand (Version/Tag) sein soll.

Quote from pbrb

mein Hauptaugenmerk liegt auf Verstehen und Fixen und Erweitern vom Code

Gerne in dieser Reihenfolge. Besser als vorhandene Features erst aus- und dann wieder einzubauen, oder anerkannte Standardloesungen ignorieren, weil es manchmal trotzdem auch anders funktioniert.

Nun ja, vieles ist Geschmacksache. Es gibt sicher verschiedene Ansichten. Etwas Toleranz von allen Seiten ist fuer ein Freizeitprojekt sicher auch nicht verkehrt.

Unbestritten duerfte sein, dass Du das Plugin weiterentwickelt und neue Features eingebaut hast, was sicher nicht nur fuer mich einen bedeutenden und gern gesehen Fortschritt darstellt. Danke dafuer.

Wie hier eine (weitere) Zusammenarbeit im Sinne eines Community-Projektes aussehen soll, verstehe ich allerdings leider noch nicht. Deine "chaotische Branch-and-Merge-Strategie", wie ich es genannt habe, ist so komplett anders als alles, was ich kenne, dass ich nicht weiss, wie ich damit umgehen soll. Anscheinend geht es anderen Leuten auch so. Und dieses Plugin sollte doch allgemein nutzbar bleiben, waere schade sonst.

Gruss,

S:oren