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 ;D
Viele Grüße
Boris
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.
mal schauen, ob man zum Release-Wechsel auch das alte PID Modul nach contrib verschieben und das neue PID20 veröffentlichen kann.
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
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
@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.
@Rudi,
Zitat@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
Zitat von: rudolfkoenig am 23 März 2014, 18:51:51
@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 ;-)).
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.
ZitatMir 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.
ZitatHabe 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
Hallo,
Zitat von: rudolfkoenig am 24 März 2014, 09:00:23
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 (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
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
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.
Zitat von: Dr. Boris Neubert am 29 März 2014, 13:40:00
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 (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.
Zitat von: papa am 30 März 2014, 10:48:36
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.
Zitat
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
Zitat von: rudolfkoenig am 30 März 2014, 09:04:33
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.
Die Passage in 99_update.pm lautet
# set path for fhem.de
my $branch = lc($BRANCH);
$branch = "SVN" if ($BRANCH eq "DEVELOPMENT");
$srcdir = $UPDATE{path}."/".lc($branch);
Ich vermute, daß es reicht, fhemupdate.pl dieselben Dateien aus branches/development nach .../SVN statt aus trunk nach .../stable auf Deinem Server zu kopieren.
An sich geht es mir nur darum, an KS300.pm und FHEMWEB.pm für Testzwecke herumschrauben zu können. ohne daß es die Masse an Anwendern stört.
Viele Grüße
Boris
ZitatIch vermute, daß es reicht, fhemupdate.pl dieselben Dateien aus branches/development nach .../SVN statt aus trunk nach .../stable auf Deinem Server zu kopieren.
Ja, aber:
- das erfordert eine fhemupdate.pl Anpassung+Test. Dass das update FHEM Modul sowas eingebaut hat, ueberrascht mich weniger, weil Martin dieses Feature unbedingt haben wollte, allerdings fuer STABLE vs DEVELOPMENT.
- ich will gar nicht damit anfangen, solche branches fuer Endbenutzer per update anzubieten, da sowas mein Supportaufwand erhoeht. Wer branches verwendet, dessen "Kunden" sollten Mitentwickler sein, und nicht Endbenutzer, die das eine vom anderen nicht unterscheiden koennen, und Probleme an falscher Stelle melden.
@Boris: ich verstehe immer noch nicht, welchen Vorteil Du Dir von branches versprichst. Ich befürchte, das Einführen solcher Branches (die ich übrigens auch völlig unabhängig vom update Prozess sehe) würde sehr viel mehr Probleme schaffen, als dass sie wirklich nützen.
Hallo,
ich verspreche mir von einem Development-Branch:
a) unter dem Aspekt der Einführung von Typen, in dem Branch Änderungen durchzuführen, die ich mit anderen teilen kann, die diese begutachten und testen, ohne den zigtausenden Anwendern von FHEM den Tag durch die dabei eingeführten BugsNebeneffekte zu verderben,
b) unter dem Aspekt, daß frische Neuerungen frische Probleme (Programmierfehler, schwer zu vermittelnde Verhaltensweisen, ...) mit sich bringen, daß im Stable-Branch nur Bugfixes gemacht werden, während im Development für die nach Neuerungen gierenden Anwender die "gefährlichen Sachen" gemacht werden (das ist das Argument, daß Martin Fischer dazu bewegt hat, überhaupt die Update-Varianten anzubieten, und dem hier weitere Entwickler anhängen).
In anderen Worten: wer es aushalten kann, sich mit einem instabilen System herumzuplagen, folgt dem Development-Branch, alle anderen bleiben bei Stable. Ich mache insbesondere deswegen auf meinem System nur noch gaaaanz selten Updates, weil es mich nervt, daß durch die Updates zu häufig etwas kaputtgeht oder anders ist als vorher.
Viele Grüße
Boris
Heute wurden beispielsweise Änderungen in fhem.pl, 91_notify.pm und 98_fheminfo eingebaut, die ich nicht als Bugfixing bezeichnen würde. Wenn ich nun davon ausgehe, dass nach Deinem Standpunkt eine solche Änderung dann nicht mehr im täglichen Update-Prozess ausgeliefert würde, sondern im Development passieren sollten, frage ich mich, ob man damit nicht die User von der laufenden Weiterentwicklung des FHEM ausschließen würde. Und zwar genau solange, bis das nächste STABLE freigegeben wird.
Wie soll man da eine Grenze ziehen bzw. in welchen Zeitabständen sollte dann eine Aktualisierung von STABLE erfolgen? Momentan ist es nach Rudis Aussage so, dass zwei Major Releases pro Jahr erfolgen sollen.
Und wer soll die anfallende Mehrarbeit, die durch mehrere Branches entstehen, machen? Bei uns im Haus ist das Change-Management eine Vollzeitstelle. Und das bei ca. 30 Entwicklern, also eine durchaus kleinere Entwicklungsgruppe als hier in fhem. Und selbst trotz Change-Management sind Probleme im Branching und bei der Freigabe nicht 100% zu vermeiden.
Moin Boris,
mein Bauch stimmt Dir zu, mein Kopf interveniert und sagt Rudi hat recht.
Es erhöht sich ja nicht nur die Arbeit für die Entwickler, sondern auch der angagiert Helfende im Forum muss bei Hilfen den Spagat hinbekommen, war das in "stable" schon drinnen, oder ist es ein Future von "testing".
Und, was ist ein Bugfix?
Gerade wenn ich mir HM ansehe, sind die Grenzen hier sehr fliessend.
Bei einem Grundlegenden Umbau wäre mMn ein geschlossener Testerkreis bestehend aus Entwicklern und Testern geeigneter.
Ich stünde da als Tester zur Verfügung.
Gruß Joachim
Zitat von: Joachim am 30 März 2014, 18:01:38
Bei einem Grundlegenden Umbau wäre mMn ein geschlossener Testerkreis bestehend aus Entwicklern und Testern geeigneter.
Ich denke auch, für grundlegende Umbauarbeiten könnte man EINEN Projektbranch für genau den geplanten Umbau anlegen. Aber der bleibt dann dauerhaft völlig unabhängig von dem, was an die Anwender geht.
Ob dann aus dem Projektbranch irgendwann einmal fhem 6.0 entsteht, sei dahingestellt. Ein Mergen von "grundlegenden Umbauten" in den bereits veröffentlichten Branch halte ich jedenfalls für wenig zielführend.
Zitat von: rudolfkoenig am 23 März 2014, 12:23:58
Eigentlich in April, aber vorher muss ich noch meine "Frontend-Hausaufgaben" machen, und die Wogen danach muessen sich beruhigt haben.
Back to the original question. :Nächster Major-Release?
@Rudolf: would you be so nice to inform us 1 week before the next Major-Release
Many Thanks
immi
Zitat@Rudolf: would you be so nice to inform us 1 week before the next Major-Release
Two weeks.