Nächster Major-Release?

[Dr. Boris Neubert]

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

Code Auswählen Erweitern


    # 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

[rudolfkoenig]

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

[betateilchen]

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

[Dr. Boris Neubert]

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

[betateilchen]

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.

[Joachim]

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

[betateilchen]

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.

[immi]

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

[rudolfkoenig]

@Rudolf: would you be so nice to inform us 1 week before the next Major-Release

Two weeks.