Entwickler Unterstützung gesucht - Release-Vorbereitung
 

Da der Editor nun einen wichtigen Meilenstein erreicht hat, wird es Zeit langsam Richtung des nächsten Releases zu schaun. Hier brauchen wir Euere Hilfe!

Im Grunde gibt es nun ein paar Phasen:

1. Feature Freeze
2. Freeze der internen Strukturen
3. Harter Freeze direkt vor dem Release

Auf einen (weichen) Feature Freeze(*) können wir uns wohl einigen, die aktuelle Version hat ja schon sehr viele Neuigkeiten, wie das ChangeLog weiß: SourceForge.net Repository - [openautomation] Contents of /CometVisu/trunk/ChangeLog

Somit würden wir als nächstes Richtung Freeze der internen Strukturen schauen - und genau da sehe ich noch Handlungsbedarf!
[HILFE]Ich such Unterstützung beim Aufräumen und polieren (neudeutsch: Refactoring) der internen Strukturen![/HILFE]
So ist z.B. die templateenginge.js inzwischen sehr "gewachsen".
Mit der der hatte ich damals angefangen, als ich noch nicht sonderlich viel über JavaScript Internas wusste... (Der iconhandler.js ist da schon deutlich weiter - und JavaScript Profis wissen sicher nochmals deutlich mehr)
=> Wer sich um was kümmern möchte, am besten vorher hier im Thread abstimmen. http://knx-user-forum.de/images/icons/icon14.gif

Wenn das durch ist, würde ich die internen Strukturen freezen und mit Test-Builds anfangen. Das wäre auch der Zeitpunkt, wo möglichst alle offenen Bugs (vgl. SourceForge.net: Open Automation: Bugs) geschlossen werden sollten.
Ggf. sind auch noch ein paar Feature Requests (vgl. SourceForge.net: Open Automation: Feature Requests) umsetzbar(*).

Wenn dann der Editor fertig ist (für den sehe ich nur die 3. Phase als relevant an!) und die Änderungsgeschwindigkeit sich stabilisiert hat, wäre es Zeit für das nächste Release.

Wann ist das? Na dann, wenn's fertig ist ;)

Also los, geht vom :b_couchi-Modus zum :b_nerd-Modus über, damit wir :b_bier und :geschenk

:b_ja

--
(*) Was ist ein weicher Feature Freeze?
Das letzte Release hat gezeigt, dass ein harter Feature Freeze für uns kein gut gangbarer Weg ist. Daher würde ich gerne einen weichen Feature Freeze probieren - d.h. Implementierung von Features die nur sehr lokale Auswirkungen haben oder nicht über den Umfang eines Bug-Fix hinaus gehen, wären dann weiterhin i.O.

Kurz ein paar Fragen von meiner Seite...

- Wie wird die CV auf dem WG aktualisiert? Direkt über Update oder wieder über cometvisu im Paketfeld? (hängt mit der nächsten Frage zusammen).

- Müsste man für die neue Releasversion ein neues "Handbuch" anlegen um mehrere Versionen bedienen zu können oder überschreiben wir einfach die bestehenden Seiten am Tag X der Veröffentlichung?

- Wie wird die Version heissen? 0.6.3?

Das fertige nächste Release: wird wohl automatisch drüber installiert.

Test-Pakete für die finale Phase der Entwicklung werden wohl anders laufen (ich stelle mir vor, eine parallele Schine aufzumachen, die sich z.B. unter /visu_test/ installiert.)

Da aber Makki die Pakete baut, wird er sicher hier noch etwas autoritatives sagen können...
Ich sehe hier keinen Grund abwärtskompatibel zu bleiben, d.h. eine Version des Handbuchs wird wohl reichen.
Sind doch einige Features dazu gekommen, d.h. ich überlege bzgl. einer 0.7.0 oder gar 0.8.0
(Da die 3D-Seiten noch nicht wirklich gehen, kann es keine 1.0.0 werden :p)

Andere Meinungen?

Ok :)

Also dan beginne ich in den nächsten Tagen mal eine Arbeitskopie des Handbuches unter Labor anzulegen damit ich (und eventuell der eine oder andere Helfer) in Ruhe mit der Aufarbeitung des Handbuches beginnen kann/können. :)

Guten Morgen,

ich würde hier schon einen Grund sehen:

Die (derzeitige) Release-Version der CV ist außerordentlich einfach in der Benutzung. Zwar durchaus eingeschränkt aber dafür mit einem WYSIWYG Editor.

Ich wäre dafür, dieses erste Release als CV-Light zu behalten. Ich fände es sehr wichtig, dass es eine Visu gibt, die fast ohne Einarbeitung zu benutzen ist und binnen zwei Stunden eine brauchbare Visu ergibt. Komplexe Visus bei denen man Tage- und Wochenlang herum malen muss, gibt es schon genug.

Die neue CV-Visu hat einen anderen Editor-Ansatz. Natürlich sehr mächtig und erweiterbarer, aber benötigt ein paar Stunden mehr Einarbeitung, dafür gibt es ausgefeiltere Designs und später dann auch 2D/3D für diejenigen, die unbedingt trotzdem malen wollen.

Die neue CV könnte man doch parallel als "CV Professional" (oder so ähnlich) anbieten.

Insofern wäre aus dieser Sicht ein separates Handbuch / Pfad erforderlich.

lg

Stefan

Ja dass war auch mein Gedanke...

Nicht jeder wird warscheinlich am Tag X auf die neue CV Version umsteigen (wenn warscheinlich auch die meisten).

- Dann könnte das neue Handbuch für grosse Verwirrung sorgen weil dazwischen Welten liegen. Alles was mit Editor zutun hat ist anders.
- Sehr viele neue Widgets und Einstellungen sind dazugekommen.
- Auch ein neues Design (Metal) was nicht abwärts kompatibel ist weil es diverse neue Attribute nutzt. (Lässt sich zwar ändern aber sieht nicht mehr soo toll aus wie auf den bekannten Screenshots)

Die Frage ist, ob man (damit es nicht zu aufwändig wird) sich auf 2 Versionen einigt?

Was meint ihr dazu?

Vorstellbar wäre, die alte Version einzufrieren und "as is" zu kennzeichnen.
Also kaum Support, keine Fixes mehr, erst recht keine neuen Sachen.

Ich würde halt ungern zwei (bzw. dann wären es ja sogar drei...) Versionen des Codes in der freien Wildbahn halten, dass wird sonst vom Support vermutlich ein Alptraum.
Deswegen hatte ich mich eher gefragt, wie automatisch das Update auf den neuen Code gehen soll (vgl. aktuell normales Update vs. Kernel-Update).

Von Light und Professional halte ich wenig, da der Code genau dar gleiche ist. Wir haben nur einen alten (per WYSIWG intuitiveren) und einen neuen (per XSD universelleren) Editor.
D.h. wenn, dann haben wir hier ein Doku-Problem das wir lösen müssen (z.B. mit einem Tutorial neben der Referenz).

Und das ich mir langfristig eine WYSIWG-Erweiterung des Editors gewünscht habe, hatte ich ja schon mal geschrieben. Dennoch ist es richtig, erst mal den XSD-Part sauber zu lösen, das andere kann man hoffentlich schmerzfrei für's folgende Release hinzufügen.

Hallo,

ich möchte Stefan beipflichten.
Ich bin sicher, dass es User gibt, die mit der CV mit dem aktuellen Editor nichts anfangen können -mit dem alten aber sehrwohl.

Was spricht dagegen, die Dokumentation mitzuliefern und in wiregateXXXX/visu_light/doc/ zu speichern.

Eine andere Möglichkeit: Kann man nicht den alten WYSIWYG Editor weiter nutzen? Damit kann man die neuen Features zwar nicht nutzen, aber sonst...
Das hätte den Vorteil, dass man nicht mehrere Codes im Umlauf hat.

Dann gäb es auch nur eine Doku, in der dann einmal der WYSIWYG Editor beschriben wird und einmal der neue. Nachteil: Es müssten Features als "Expertenfeatures" dokumentiert werden (eben alles neue, was mit WYSIWYG nicht geht).
Andererseits: Die "light" Version wird ja v.a. von Leuten benutzt werden, die nicht so auf Handbücher stehen ;-)

Gruß,
Hendrik

Ich sehe nicht, das der neue Editor nun sooo kompliziert ist. Das ist in vielen anderen Programmen auch so, das es ein wenig Einarbeitung bedarf (die ersten Seiten werden trotzdem nach 30 Minuten herauspurzeln).

Ansonsten könnte man noch den alten Status forken, bischen aufhübschen und selber betreuen...