Delphi Beta-Versions - Teilnahme

[philipp.hofmann]

Also ich kann auch nur unterschreiben: Wenn man einen Fehler behoben haben möchte, hilft die Teilnahme an der Beta, aber es bedeutet auch Arbeit, dessen sollte man sich bewusst sein. Weil oft reicht es nicht aus, nur den Issue im Portal aufzumachen, sondern man muss versuchen ein Mini-Projekt mit reproduzierbaren Verhalten schreiben, dann wieder jeden Build mit einem potentiellen Fix des Issues installieren und den Issue testen, ...

Das kennt ihr von eurer eigenen Arbeit, manchmal bedeutet dies 2-3 Runden. Aber man ist jedem Kunden dankbar, der diesen Weg mitgeht.

[Frickler]

Zitat von DieDolly:

In 10.3.3 gibt es noch immer den Bug, dass man Text markiert und Entf drückt, er nicht entfernt wird.
Im weiteren Verlauf bleibt der Text einfach markiert, löscht text der davor steht beim Weitertippen, STRG+C funktioniert dann auch nicht mehr richtig.

Den gibts (mindestens) schon seit Delphi 5. Und die Abhilfe ist noch immer die gleiche: in den Optionen "persistente Blöcke" einmal an- und dann wieder abschalten.

[Rollo62]

Zitat von philipp.hofmann:

Aber man ist jedem Kunden dankbar, der diesen Weg mitgeht.

Ich mache dabei auch mit, und stelle Emba meine Mitarbeit kostenlos zur Verfügung.
Trotzdem darf ich mögliche Ergebnisse daraus nicht direkt nutzen, das halte ich schon für etwas unfair.

Aber vielleicht verstehen die meisten hier den Druck unter Android/iOS nicht,
den man alle drei Monate hat wenn wieder eine neue OS-Version den AppStore-Upload oder Linken, Debuggen unmöglich macht, nur weil das neue Feature (manchmal ein simpler XML-String) noch nicht in der IDE unterstützt wird.
Es wird dann im Web immer hektisch nach halbreifen Workarounds gesucht, die man dann bis zum eigentlichen FIX in der IDE einbauen muss, statt das Emba da einfach zeitnah kurze und schnelle Bugfixes anbieten würde.

Das letzte was ich solchen Situationen möchte, ist mir noch Gedanken über mögliche Lizenzprobleme bei Beta's machen, wenn eine neue Version wieder lauffähig ist.
Wem ist denn damit geholfen ?

Falls Emba da keine "Betriebsgeheimnisse" verraten möchte, meinetwegen,
dann sollen sie doch getrennte NDA's für Windows und für andere Platformen machen.
Ich habe gar nicht vor Geheimnisse zu verraten, ich möchte in der Regel nur meine App weiter in den Store laden können.
Wenn es bei Emba um "Firmeninteressen" geht, ist das bei mir mindestens genauso.
Auch ich verdiene damit meine Brötchen, das scheint Emba gerne zu vergessen.

[Uwe Raabe]

Zitat von philipp.hofmann:

Wenn man einen Fehler behoben haben möchte, hilft die Teilnahme an der Beta

Im Umkehrschluss bedeutet das dann auch, dass ohne Beteiligung an der Beta die Wahrscheinlichkeit der Behebung der eigenen Issues eher sinkt, da ja die der Beta-Tester-Bugs steigt und die Gesamtkapazität gleich bleibt.

Zitat von philipp.hofmann:

Weil oft reicht es nicht aus, nur den Issue im Portal aufzumachen, sondern man muss versuchen ein Mini-Projekt mit reproduzierbaren Verhalten schreiben, dann wieder jeden Build mit einem potentiellen Fix des Issues installieren und den Issue testen

Meine eigene Erfahrung ist, dass Tickets in QP schneller behoben werden, wenn die nötigen Schritte zur Reproduktion möglichst einfach sind. Im Idealfall liefert man gleich einen Unit-Test mit, der nach dem Download gleich gestartet werden kann und fehlschlägt. Wenn man dann noch die Ursache beschreibt (so das denn überhaupt möglich ist) und einen brauchbaren Vorschlag für einen Fix mitliefert, dann schadet das auch nicht. Nicht immer wird es dann auch so umgesetzt, aber das kann verschiedene Gründe haben.

Manchmal muss man auch ein bisschen über den Tellerrand schauen und eventuell etwas Zeit in die Analyse der Umgebung stecken: Passiert es nur mit einem Delphi auf Deutsch oder einem Windows auf Deutsch bzw. bei welcher Windows Version. Bei grafischen Problemen - wie ist das Monitor-Layout und die Auflösung bzw. Skalierung. Macht sicher manchmal eine Menge Arbeit, aber wenn ein Bug nicht bei Embarcadero reproduzierbar ist wird er in der Regel erstmal wieder auf Eis gelegt bis sich irgendwann mal wieder jemand darum kümmert.

[sh17]

@Rollo62 deswegen bin ich stark für eine Trennung von IDE und Komponenten. Indy, VCL, FMX und vieles mehr, warum ist das an die IDE-Version gekoppelt? Geht mit dem binär-Format der DCUs weiter, das sich von jeder Hauptversion zur nächsten ändert. Ich möchte kein Komponentenhersteller sein, der seine Demos bis Delphi 6 zurück anbietet - Horror. Ich würde sogar noch weiter gehen. VCL etc OpenSource... wie .NET. Da wird der Fokus vielleicht wirklich mal auf die IDE gelegt und gezwungen Qualität abzuliefern. Würde natürlich auch bedeuten, das sich Emba selbst den Ast absägt, auf dem es sitzt.

//Noch ein Argument für OpenSource der VCL - es würde eine Basis schaffen, weitere Plattformen zu ergänzen ohne Probleme mit der Lizenz zu bekommen. Oder auch solche Ansätze wie CrossVCL hätten einen Sinn, diese öffentlich zu machen.
Klar, gibt FreePascal - was ich mir diesbezüglich auch anschaue und stark am Überlegen bin, damit den MacOS-Part zu schreiben

[Der schöne Günther]

Ein erster vorsichtiger Schritt wäre vielleicht einmal, die eigenen Unit-Tests Open Source zu machen, aber das wollte man leider auch nicht 😐

[sh17]

Zitat von Der schöne Günther:

Ein erster vorsichtiger Schritt wäre vielleicht einmal, die eigenen Unit-Tests Open Source zu machen, aber das wollte man leider auch nicht 😐

"Vielleicht gibt's ja keine."

[TurboMagic]

Doch gibt es, nur nicht genügend...

[himitsu]

Zitat von philipp.hofmann:

Also ich kann auch nur unterschreiben: Wenn man einen Fehler behoben haben möchte, hilft die Teilnahme an der Beta, aber es bedeutet auch Arbeit,

Oder du machst es wie alle Anderen.
Nachher die Fehler finden ... dann darfst dich auch öffentlich drüber lustig machen, ohne exkommuniziert zu werden.

[DieDolly]

Zitat:

Den gibts (mindestens) schon seit Delphi 5.

Ein Grund mehr den zu priorisieren. Vielleicht meldet den ja einer in der Beta.