Nächster Major-Release?

[Dr. Boris Neubert]

Hallo Rudi,

ist demnächst ein neuer Release von FHEM geplant?

Ich frage das, weil ich mir überlegt habe, daß es schöner ist, die mindestens 250 ECMD-Installationen aufgrund fehlender Abwärtskompatibilität mit einem neuen Release zu zerschießen statt so nebenbei per Update 

Viele Grüße
Boris

[rudolfkoenig]

Eigentlich in April, aber vorher muss ich noch meine "Frontend-Hausaufgaben" machen, und die Wogen danach muessen sich beruhigt haben.

Falls du keine Lust mehr auf Abwaertskompatibilitaet hast, dann schlage ich vor das Modul umzubenennen (ECMD2 ?), den alten als "deprecated" markieren und nach eine Weile ins contrib zu verschieben. Dann ist keiner ueberrascht, und wer die neuen Features haben will, kann ja wechseln. Ich habe das gerade mit JsonList2 exerziert.

[betateilchen]

mal schauen, ob man zum Release-Wechsel auch das alte PID Modul nach contrib verschieben und das neue PID20 veröffentlichen kann.

[Joachim]

Moin Rudi,
konstruktiver Vorschlag zum neuen Release:
Bitte eine klare Unterscheidung schaffen zwischen der Downloadversion, welche nach einem Tag veraltet ist, also FHEM 5.6 und der Version aus dem Trunk also z.B. 5.6.1
Mir ist im Forum aufgefallen, dass viele neue User der Meinung sind, sie hätten die neueste Version, da gestern heruntergeladen.
Manchmal kommt das erst durch Zufall heraus, da die aktuelle Version die gleiche Bezeichnung hat. Beides FHEM 5.5.
Gruß Joachim

[ntruchsess]

wie wäre es denn, wenn wir mal richtig mit Branches und Tags arbeiten würden?

Major-Release = Tag a la 'FHEM_5_5' (haben wir schon)
nach Major-Release: Maintenance des Major-releases in einem Branch 'FHEM_5_5_maintenance'
fortlaufendes Development: weiterhin im Trunk.

Mit sowas könnte man kleinere und besser getestete Bugfixes auch den Benutzern zugute kommen lassen, die nicht immer die 'bleeding edge' Development-version (mit allen Risiken bei einem update mal wieder die neuesten Bugs einzuspielen) einsetzen wollen.

Point (5.5.1)-releases werden dann als Tags der Maintenance-branches generiert, Major-releases als Tags des Trunks.

Gruß,

Norbert

[rudolfkoenig]

@Joachim: ich versuche das auf fhem.de zu erklaeren. Bin aber skeptisch, viele haben verlernt zu lesen.

@Norbert: diese Diskussion gab es auch frueher, und ich habe es abgelehnt, mit folgender Begruendung:
- ich habe keine Energie mehr als eine Version zu fixen / testen und zu supporten.
- wir haben kurz mit sowas experimentiert, mit dem Ergebnis dass keiner die Entwicklung getestet hat (nicht mal die anderen Entwickler), und man hat erst bei der Umwandlung von Entwicklung in Release die Probleme entdeckt, ein paar Monate spaeter. Das ist aber zu spaet.
- keiner ist gezwungen ein update zu machen. Wenn man sowas trotzdem macht, sollte einem bewusst sein, ein freiwilliger Tester zu sein.

Martin hat sich damals fuer STABLE/DEVELOPMENT stark gemacht, wie man das in der Ausgabe von fheminfo sieht.

[Joachim]

@Rudi,

@Joachim: ich versuche das auf fhem.de zu erklaeren. Bin aber skeptisch, viele haben verlernt zu lesen.

wäre meiner Meinung nach vollkommen ausreichend, habe die Diskussion von damals noch gut im Gedächniss. Mir ist auch klar, dass die wenigsten die Erklärung lesen, aber dann kann man sie wengstens hauen. Die bisherige Variante weist halt nicht wirklich darauf hin.

Gruß Joachim

[ntruchsess]

@Norbert: diese Diskussion gab es auch frueher, und ich habe es abgelehnt, mit folgender Begruendung:
- ich habe keine Energie mehr als eine Version zu fixen / testen und zu supporten.

Ein Release aktiv (mit Stabilitätsfixes) zu supporten macht natürlich Aufwand. Mehr Aufwand wäre aber sicher nicht das Ziel

Die Frage ist halt, wie man Aufwandsminimierung und gute Release-stabilität kollobarativ und einfach unter einen Hut bekommt. Wenn man im Trunk auf ein Release hinarbeitet, dann muss man vor dem Release einen 'Feature-freeze' machen, ab dem ausschließlich Bugs behoben werden. Macht man das nicht, hat man vieleicht irgendein unausgereiftes Modul oder eine halbfertige Überarbeitung im Release-tag. Man könnte ja z.B. 3 Wochen vor Release einen Release-candidate-branch abzweigen, in den dann nur noch wenige - stabilitätsrelevante - Fixes reinkommen.

Das Arbeiten mit Branches erlebe ich in anderen Projekten übrigens als eine deutliche Erleichterung. Nicht wegen der Maintenance von Releases (das findet in OS-projekten eh eher selten statt), sondern wegen der Möglichkeit andere sehr frühzeitig und auf sehr einfache Weise an der eigenen Entwicklung teilhaben zu lassen.
Hier bei fhem kocht jeder sein eigenes (lokales) Süppchen und posted Testversionen als Attachments im Forum um möglichst ausgereiften Code in den Trunk zu committen. In der Phase können andere nur sehr eingeschränkt (eigentlich nur als Tester) unterstützen. (Wenn man zu einem als Attachment geposteten Stück code was beitragen will, dann kann man eigentlich nur eine patch-datei dranhängen, in der Hoffnung, dass die dann zum mittlerweile lokal weiterentwickelten Stand passt). In meinen anderen Projekten verwende ich fast ausschließlich Git (mit SVN habe ich etliche Jahre gearbeitet, mit CVS auch... also an Erfahrung damit mangelt es nicht). Mit Git ist es supereinfach, dass jeder seine Features im eingenen Branch (bzw. Repository-clone) bearbeitet und dann das Ergebniss per Pull-request in den Trunk (aka 'master') einbringt. Einen Patch zu einem Arbeitsstand eines Moduls schickt man auch einfach als Pull-request gegen diesen Branch. Das geht wirklich so einfach, dass man sich fragt, wie man ohne sowas überhaupt vernünftig zusammenarbeiten kann, wenn man es erst mal nutzt. Beim Mergen von Branches ist Git auch um Klassen schlauer als SVN. Merge-konflikte gibt's da wirklich nur, wenn es echte Konflikte sind.
Sollte man jedenfalls mal drüber nachdenken, ob man sich damit das Leben erleichtern könnte.
(In Git ist man übrigens nicht gezwungen Feature-Branches zu machen, man kann jederzeit auch direkt in den master committen, aber wenn man es machen will, dann sind die Hürden sehr sehr niedrig ).

[rudolfkoenig]

Ich habe kein Problem mit solchen branches, falls jemand es nuetzlich findet, soll er es verwenden. Ich habe nur gesehen, dass ein "erzwungenes" Developer-branch nicht aktiv verwendet wurde.
Btw. die Werbung fuer git habe ich gehoert, aber ich weiss, wieviel Aufwand ein Umstieg ist, und ich z.Zt. keine Probleme mit SVN habe, deswegen bleibt FHEM erstmal bei SVN.

[rudolfkoenig]

Mir ist im Forum aufgefallen, dass viele neue User der Meinung sind, sie hätten die neueste Version, da gestern heruntergeladen.

Habe eine entsprechende Warnung auf fhem.de im Download-Abschnitt jetzt schon eingebaut, ist ja nicht unbedingt release-Spezifisch.

[Joachim]

Habe eine entsprechende Warnung auf fhem.de im Download-Abschnitt jetzt schon eingebaut, ist ja nicht unbedingt release-Spezifisch.

Auch, wenn es eventuell nicht gelesen wird, Danke, sieht gut aus

Gruß Joachim

[Dr. Boris Neubert]

Hallo,

Ich habe kein Problem mit solchen branches, falls jemand es nuetzlich findet, soll er es verwenden.

für einige größere Änderungsvorschläge, die im weiteren Kreise von Entwicklern begutachtet diskutiert werden sollen (Typen, siehe http://forum.fhem.de/index.php/topic,21247.msg154014.html#msg154014), möchte ich einen Development-Branch anlegen, wobei der Stable-Branch (TRUNK) regelmäßig in den Development-Branch gemergt wird.

Frage dazu: ist der Mechanismus schon aktiv, der es mir nicht nur erlaubt, in FHEM per

Code Auswählen Erweitern

update development auf einen Development-Branch zu wechseln, sondern auch darüber neue Dateien aus dem Development-Branch statt aus TRUNK zu erhalten?

Viele Grüße
Boris

[rudolfkoenig]

Es wuerde mich wundern, wenn update neben dem aktuellen trunk irgendetwas anderes anzapfen kann.
Ich habe den code in update.pm seit Martins Umbau nicht wirklich durchgeschaut oder gar verstanden, aber die Daten stelle ich auf fhem.de zur Verfuegung, und das erfordert fuer jedes neue Verzeichnis manuelle Arbeit.

[papa]

für einige größere Änderungsvorschläge, die im weiteren Kreise von Entwicklern begutachtet diskutiert werden sollen (Typen, siehe http://forum.fhem.de/index.php/topic,21247.msg154014.html#msg154014), möchte ich einen Development-Branch anlegen, wobei der Stable-Branch (TRUNK) regelmäßig in den Development-Branch gemergt wird.

Ist den dafür wirklich ein extra Branch nötig. Ich sehe hier akut die Gefahr, dass der Aufwand für das Merge über die Zeit sehr groß wird. Wenn die neue Funktionalität durch eine separate API zur Verfügung gestellt wird, sollte das doch voll transparent umzusetzen sein. Ich denke, dass wir um eine volle Rückwärtskompatibilität eh nicht drum herm kommen werden.

Das Einführen der Typen stört doch erst mal niemanden. Ebenso Funktionen, welche die Werte entsprechend liefern - Numerisch, Formatiert, Umgerechnet, ....

Spannend wird es sicherlich, wenn das (Frontend|Web)modul dran ist. Ohne jetzt zu wissen, wie es genau drin aussieht und funktioniert, wäre hier vielleicht eine vorherige Umstrukturierung angebracht, damit dann eine umschaltbare Parallelimplementierung der Darstellung erfolgen kann. Damit würde die Möglichkeit bestehen, dass sich die aktuelle Entwicklung nicht von der "Development-Test-Entwicklung mit Typen" entfernt.

[Dr. Boris Neubert]

Ist den dafür wirklich ein extra Branch nötig. Ich sehe hier akut die Gefahr, dass der Aufwand für das Merge über die Zeit sehr groß wird.

Die Gefahr sehe ich nicht, weil ja nur regelmäßig ein svn merge [--reintegrate] erforderlich ist.

Wenn die neue Funktionalität durch eine separate API zur Verfügung gestellt wird, sollte das doch voll transparent umzusetzen sein. Ich denke, dass wir um eine volle Rückwärtskompatibilität eh nicht drum herm kommen werden.

Das Einführen der Typen stört doch erst mal niemanden. Ebenso Funktionen, welche die Werte entsprechend liefern - Numerisch, Formatiert, Umgerechnet, ....

Hierin bin ich mit Dir einer Meinung.

Mein Punkt ist nur, daß ich für einen Funktionstest auch Module anfassen muß, die mir nicht gehören: KS300 und FHEMWEB. Bei KS300 kann ich Rudi vielleicht noch überzeugen, mir die Pflege zu übertragen, zumal ich wesentliche Teile daran mitentwickelt hatte. Bei FHEMWEB steht das aber außer Frage.

Arbeiten mit einem Branch bringt mir keinen besonderen Lustgewinn. Wenn wir ohne auskommen, bin ich auch glücklich. Ideen?

Viele Grüße
Boris