Neu JTL Updates mit oft neuen Fehlern

[Enrico W.]

Doch, ich denke schon.
RC = Beta. Erst closed beta, dann open beta.

Daraus leitet sich dann die stable ab. Die Frage ist jetzt eher - was verstehst Du unter der stable? Oder warum sind die releases für Dich nicht stable?

 

[MichaelH]

Nö, es geht darum, dass ihr neue Begriffe geschaffen habt.

Dann ist die 1.7.8.3 = 1.7.9 ohne weitere Änderungen und Gratis-Einbau von Bugs ?
Denn eine Beta 1.7.9 gibt es gar nicht, also müsste die 1.7.9 identisch mit 1.7.8.3 sein.

Wenn nicht, dann wird die Stable 1.7.9 so stable sein wie die 1.7.8 für die dann die 1.7.8.1 und die 1.7.8.2 und die 1.7.8.3 innerhalb von 10 Tagen nötig wurden ?

Daher - ist nun die 1.7.8.3 die Stable oder ist es die 1.7.9 ?

 

[Verkäuferlein]

So ganz verstanden habe ich das jetzt auch nicht.

In der 1.7.9.0 sind ja auch Bugs gefixed worden, dann müsste es ja theoretisch auch eine 1.7.8.4 geben, in der auch die Bugs gefixed sind, aber keine sonstigen Änderungen gegenüber der 1.7.8.0!?

 

[Enrico W.]

Die 4. Ziffer gibt an, dass es sich dabei um Fixes handelt, die nicht warten konnten. Betrachtet diese Version deshalb als Hotfix. Gleichzeitig kann es auch sein, dass diese Hotfix-Versionen bereits die Stable darstellen, weil vor Release bereits wichtige Fehler aufgefallen waren.
Ab einem gewissen Punkt in der Entwicklung muss man eine Version dann auch schließen um nicht ewig diesen Mini-Versionen hinterherzurennen. Dann ist es sinnvoll, die Fixes in die nächste "normale" Version fließen zu lassen - und das ist die 1.7.9.0.
Wieso sollte diese identisch sein mit der 1.7.8.3? Weil ihr da keine großen Updatemeldungen bekommt?

 

[MichaelH]

Gut, wir lernen also dass wir auf die 4. Kommastelle wissen sollten was das nun zu bedeuten hat ...

Hast du mein https://forum.jtl-software.de/threads/jtl-updates-mit-oft-neuen-fehlern.202261/page-2#post-1079884 überhaupt gelesen und aus Anwendersicht mal betrachtet und überlegt ?
Einerseits erklärst du wie es läuft und andererseits hält sich JTL nicht daran.

Lt. deiner Defintion gab es für 1.7.8, die 1.7.8.1 und die 1.7.8.2 und die 1.7.8.3 innerhalb von 10 Tagen 4 Stable Versionen.
Und für die 1.7.9 gab es gar keine RC = Beta, erst closed beta, dann open beta, aber darauf gehst du gar nicht ein.

-> Daher wie schon von mir gesagt, es wäre sinnvoll wenn JTL eine STABLE festlegt, auch wenn es eine im Nachinein ist wie z.B. die 1.7.8.3 (?) wenn es darin keine schwerwiegende Bugs gibt.

Man lässt sich verleiten eine 1.7.9 als Stable zu betrachten, dabei ist diese genau das Gegenteil.

Ergänzung:
Es mag JTL-user geben die sofort alles runterladen, weil sie mit einem aktuellen Bug zu kämpfen haben.
Aber es gibt auch JTL-User die zufrieden damit wären, wenn JTL z.B. 1 x im Monat eine Version als "stable" bezeichnet, auch wenn es nicht die aktuellste ist, aber die bekannten Bugs darin als nicht schwerwiegend (und bekannt) beurteilt werden.

Denn so wie es aktuell läuft hat man Sorge in diese Zwangs-Update-Spirale zu gelangen mit immer neuen Bugs durch die aktuellste Version.
Verstanden ?

 

[Enrico W.]

Ich fürchte, wir drehen uns im Kreis. Ich habe mehrfach gesagt, dass die Version 8.2 und 8.3 mindestens als hotfix zu sehen sind.
Warum die 1.7.9.0 nicht als stable zu sehen ist schreibst du mehrfach, aber in meinen Augen nicht, warum. Was ist denn das Gegenteil einer Stable? Zu welchen Aussagen willst Du mich hier bekommen? Oder wo wie wollt ihr die stable dann definiert haben? Im Namen? Gestern stable heute nicht mehr?
Wo soll diese Diskussion letztlich hinführen?

 

[Verkäuferlein]

Wo soll diese Diskussion letztlich hinführen?

Aus meiner Sicht dahin, dass man weiß, wie man eine möglichst stabile (stable) Version findet, die sich längerfristig betreiben lässt, ohne dass man in die Abhängigkeit gerät den einen Bug beheben zu müssen, damit aber den anderen Bug einzuspielen und sich dies beliebig oft fortsetzt.

Also eine Art "LTS Wawi-Version", bei der halt nur Bugs bereinigt werden und langzeit-erprobte Features einfließen. Die also stabil und verlässlich ist.

 

[MichaelH]

"Warum die 1.7.9.0 nicht als stable zu sehen ist schreibst du mehrfach, aber in meinen Augen nicht, warum. "
-> Doch mehrfach geschrieben, es gab keine Closed-Beta der 1.7.9.0, sondern die Version wurde einfach rausgehauen, also das Gegenteil von stable.


Und um was es geht ist nach wie vor -> was ist dir bitte an diesen 2 Sätzen nicht klar ?

Stabile Version
Ist die öffentliche Testphase eines Produktes durchlaufen und die dabei entdeckten Probleme beseitigt, prüfen wir, ob ein Release Candidate nun zur neuen stabilen Version wird. Die von uns angebotene stabile Version ist nicht zwangsläufig der direkte Vorgänger des aktuellen RC, sondern die neuste, stabilste Variante von JTL-Wawi in unserem Produktkatalog.

-> Also, was ist daran unklar und wie soll ich diese bitte erkennen ? Ist die stabilste Variante nun 1.7.9.0 oder 1.7.8.3 oder irgendeine vorgängige Version ?

 

[Enrico W.]

Aus meiner Sicht dahin, dass man weiß, wie man eine möglichst stabile (stable) Version findet, die sich längerfristig betreiben lässt, ohne dass man in die Abhängigkeit gerät den einen Bug beheben zu müssen, damit aber den anderen Bug einzuspielen und sich dies beliebig oft fortsetzt.

Also eine Art "LTS Wawi-Version", bei der halt nur Bugs bereinigt werden und langzeit-erprobte Features einfließen. Die also stabil und verlässlich ist.

Und damit wären wir wieder fast am Anfang - Siehe Beitrag #4

@MichaelH Selbst nach Deiner Definition ist die 1.7.9.0 die stabilste Version, da dort die Bugfixes mit reingeflossen sind, auch wenn es jetzt keine extra closed beta dafür gegeben haben mag.

Ich weiß ja, dass Eure Erfahrungen wg. Updates nicht immer die Besten waren. Aber siehe Beitrag #4 - wir arbeiten daran und das sehr hart.
Hier drehen wir uns aber gerade im Kreis.

 

[SebiW]

Ich denke was Michael sagen möchte ist, dass Kunden sich unter einer Stable etwas anderes vorstellen als das, was derzeit unter diesem Begriff läuft. Ein Stable definiert sich aus dieser Perspektive darüber, dass alle in der Version enthaltenen Prozesse ohne schwerwiegende Fehler sind und diese Version, so nicht äußere Zwänge eintreten, längerfristig nicht geändert werden muss. Ein gutes Beispiel wären vielleicht die LTS Versionen von Firefox.
Also eine Version, die darauf ausgelegt ist langfristig betrieben zu werden und bestenfalls nur Sicherheitspatches benötigt.

JTL definiert eine Stable als jede Version, die released und für die Verwendung durch alle User freigegeben ist.

Der zentrale Unterschied ist die Frage: Wie oft muss ich ein laufendes System anfassen. Die Stables nach Muster 1 müssen nicht angefasst werden bis entweder sicherheitsrelevante Patches erscheinen, der User Bedarf an weiteren Funktionen hat oder der LTS ausläuft. Die Stables nach Muster 2 setzen einen dauerhaften Upgradeprozess durch die Anwender voraus, was in größeren Umgebungen ... fordernd ist.

Und ja, auch wir würden uns wünschen, dass es in regelmässigen Abständen Versionen gibt, die ausschließlich auf Fehlerbehebung optimiert sind. Allerdings vermute ich mal, dass es für JTL sehr schwer wäre mehrere Produktlinien gleichzeitig hinreichend zu pflegen und zu supporten.

 

[Enrico W.]

Das verstehe ich doch auch, nur lässt sich das eben nie immer zu 100% sagen. Es kann immer zu Fehlern kommen, die nicht mit generischen Daten gefunden werden können oder die bestimmte Konstellationen brauchen. Dennoch sind diese Fehler natürlich schwerwiegend. Da beißt die Maus keinen Faden ab.
Nur - was soll dann hier eine Diskussion um die Begrifflichkeiten, insbesondere wenn die teilweise von Usern kommen, die bewußt schon lange nicht upgedatet haben? Da beißt sich die Katze selbst in den Schwanz. Wenn wir eine Version als Stable betrachten, dann kann das in einer Woche schon wieder anders aussehen - oder muss sogar, weil sich nicht nur unsere Anforderungen sondern auch Anbindungen Dritter weiterentwickeln.
Daher weiß ich schlichtweg nicht, was hier nun noch erwartet wird.

 

[MichaelH]

@MichaelH Selbst nach Deiner Definition ist die 1.7.9.0 die stabilste Version, da dort die Bugfixes mit reingeflossen sind, auch wenn es jetzt keine extra closed beta dafür gegeben haben mag.

Gut, dann bewirb' dich als Hellseher, denn wir alle haben keine Ahnung was ihr da für Bugs eingebaut habt, ausgenommen dir ... es ist ein völliger Trugschluss, dass die letzte Version die beste Version ist.
Aber leider willst du mich und uns nicht verstehen ...

Vielleicht solltest du mal mit demjenigen sprechen der "damals" den Text geschrieben hat, den ich nun schon mehrmals zitiert habe, denn der versteht ganz bestimmt von was ich schreibe.
Warum ?

"Die von uns angebotene stabile Version ist nicht zwangsläufig der direkte Vorgänger des aktuellen RC, sondern die neuste, stabilste Variante von JTL-Wawi in unserem Produktkatalog."

-> ER hat erkannt, dass nicht mal "der direkte Vorgänger des aktuellen RC" die beste Version sein muss, geschweige denn das aktuelle RC, nur du bist anderer Meinung und willst uns die aktuellste Version als die Beste verkaufen. 😉 Denk mal drüber nach, an der Kaffeemaschine, in aller Ruhe.

 

[MichaelH]

Nur - was soll dann hier eine Diskussion um die Begrifflichkeiten, insbesondere wenn die teilweise von Usern kommen, die bewußt schon lange nicht upgedatet haben?

Ui ui ui ui, ja, ich überlege mir sehr gut ob ich update und wann. Immerhin bin ich Beta-Tester.
Und wenn ich dann konkret das Thema angehe frage ich mich welche Version wohl die BESTE ist.

Heute müsste ich sagen: Keine Ahnung, ist ein Glücksspiel.

Und das darf gerne besser werden.

 

[SebiW]

Das verstehe ich doch auch, nur lässt sich das eben nie immer zu 100% sagen. Es kann immer zu Fehlern kommen, die nicht mit generischen Daten gefunden werden können oder die bestimmte Konstellationen brauchen. Dennoch sind diese Fehler natürlich schwerwiegend. Da beißt die Maus keinen Faden ab.
Nur - was soll dann hier eine Diskussion um die Begrifflichkeiten, insbesondere wenn die teilweise von Usern kommen, die bewußt schon lange nicht upgedatet haben? Da beißt sich die Katze selbst in den Schwanz. Wenn wir eine Version als Stable betrachten, dann kann das in einer Woche schon wieder anders aussehen - oder muss sogar, weil sich nicht nur unsere Anforderungen sondern auch Anbindungen Dritter weiterentwickeln.
Daher weiß ich schlichtweg nicht, was hier nun noch erwartet wird.

Ich verstehe Eure Perspektive natürlich. Aber der Wunsch ist ja gar nicht: Wir wollen eine tagesaktuelle Version, die keine Fehler hat. Was Michael denke ich meint ist das es wünschenswert wäre, wenn es neben dem Rolling Release noch eine zweite Releasebene gäbe, die auf der stabilsten letzten Major aufsetzt, ausschließlich Bugfixes implementiert und auch im Nachgang nur Bugfixes bekommt soweit nötig. Also eine Version, die einen exakt definierten Funktionsstand hat (und diese auch nicht ändert) und ausschließlich auf Stabilität hin optimiert wird. Und wenn dann der Bedarf des Users da ist aktuellere Versionen zu nutzen, etwa weil er weitere Marktplatzanbindungen braucht, dann ist das eine aktive Entscheidung weg von Stabilität hin zu Funktionsumfang. Die 1.5.55.6 zb war da schon ziemlich nah dran. Aber wir wollen SCX deshalb -> 1.7 😉

 

[MichaelH]

Siehst du und ich lebe sehr gut mit der WAWI 1.5.36.2 und das seit Jahren.

1.7. ist schön und will ich auch haben und ich denke du hast nun verstanden um was es "uns" geht.
Nicht die zwanghaft neueste, sondern die beste Version der 1.7.x irgendwann zu installieren und mit Empfehlung von JTL, mir egal, JTL kann eine solche "stable" 1 x im Monat oder 1 x im Quartal, alle 6 Monate festlegen.

-> Diese "Abschlussarbeit" zu einer Version sollte JTL ab und zu machen.

 

[Verkäuferlein]

Siehst du und ich lebe sehr gut mit der WAWI 1.5.36.2 und das seit Jahren.

1.7. ist schön und will ich auch haben und ich denke du hast nun verstanden um was es "uns" geht.
Nicht die zwanghaft neueste, sondern die beste Version der 1.7.x irgendwann zu installieren und mit Empfehlung von JTL, mir egal, JTL kann eine solche "stable" 1 x im Monat oder 1 x im Quartal, alle 6 Monate festlegen.

-> Diese "Abschlussarbeit" zu einer Version sollte JTL ab und zu machen.

Das grundlegende Problem ist wahrscheinlich, dass im Moment an so vielen Funktionen gewerkelt wird und auf neue Technologie umgestellt wird, dass ein einfaches Bugfixing in alten Versionen gar nicht mehr sinnvoll möglich ist.

Aber vielleicht wird es ja in Zukunft mal eine richtige Trennung zwischen "heiklen" Neuerungen und purem Bugfixing geben, wenn es eine entsprechende neue Struktur in der kompletten Wawi gibt.

 

[mgaertner]

Ohne die ganzen "Verschlimmbesserungen" der neuen Versionen hätten die Mitarbeiter ja sonst auch nichts zu tun 😉 Ich finde es auch sehr schade das die Qualität von JTL sehr abgenommen hat. Ich sag nur als Gold Support auf den garantierten Rückruf innerhalb von 4 Arbeitsstunden 5 Tage warten und und und.

 

[Rektor]

Auch wir haben uns noch nicht gewagt, von der Wawi 1.5,55.0 ein Update auf eines der neueren Versionen durch zu führen. Der Punkt ist, das jede neue Version wieder Fehler aufweist, welche bei den Funktionen vorher nicht vorhanden waren. Es ist immer wieder ein Glücksspiel, ob die Update-Version halbwegs funktioniert. Auch wie MichaelH bereits angedeutet hat, blickt man überhaupt nicht mehr durch, welche Version Stable ist und welche nicht. Anzumerken ist, das eine JTL-Wawi Version noch nie komplett fehlerfrei war.

Mitarbeiter von JTL:
Bringt endlich eine geordnete Update-Liste heraus, woran der User klar erkennen kann, woran er ist bei einem Update auf Version XXX ist.
"Stable" bedeutet für mich, dass das Produkt ohne nennenswerte Fehler benutzt werden kann, alles andere ist nicht "Stable".
Bisher konnten wir nicht erkennen, das eine Version 1.7.XX in irgendeiner Weise genutzt werden kann.
Jeder Software-Hersteller sollte einen Vorteil der neuen Version suggerieren, um den Nutzer möglichst schnell zum Update zu bewegen. Bei JTL sieht es allerdings so aus, sodass der Nutzer lieber bei der "alten" Version bleibt, um keine bösen Überraschungen erleben zu müssen.
Das ganze ist schon sehr TRAURIG...

 

[aadursun]

Auch wir haben uns noch nicht gewagt, von der Wawi 1.5,55.0 ein Update auf eines der neueren Versionen durch zu führen. Der Punkt ist, das jede neue Version wieder Fehler aufweist, welche bei den Funktionen vorher nicht vorhanden waren. Es ist immer wieder ein Glücksspiel, ob die Update-Version halbwegs funktioniert. Auch wie MichaelH bereits angedeutet hat, blickt man überhaupt nicht mehr durch, welche Version Stable ist und welche nicht. Anzumerken ist, das eine JTL-Wawi Version noch nie komplett fehlerfrei war.

Mitarbeiter von JTL:
Bringt endlich eine geordnete Update-Liste heraus, woran der User klar erkennen kann, woran er ist bei einem Update auf Version XXX ist.
"Stable" bedeutet für mich, dass das Produkt ohne nennenswerte Fehler benutzt werden kann, alles andere ist nicht "Stable".
Bisher konnten wir nicht erkennen, das eine Version 1.7.XX in irgendeiner Weise genutzt werden kann.
Jeder Software-Hersteller sollte einen Vorteil der neuen Version suggerieren, um den Nutzer möglichst schnell zum Update zu bewegen. Bei JTL sieht es allerdings so aus, sodass der Nutzer lieber bei der "alten" Version bleibt, um keine bösen Überraschungen erleben zu müssen.
Das ganze ist schon sehr TRAURIG...

Ja ich traue mich auch nicht, die neuen Versionen Kunden zu empfehlen. Da bringt es auch nicht neue Features anzupreisen, wenn Standard Prozesse nicht funktionieren.

 

[gnarx]

Moin. Also ganz so düster wie heir in den letzten Threads geschildert ist es nun auch nicht. Es gab im letzten Jahr keine Version wo man eine Vorgänger Version per Backup zurückspielen musste.
Meist kann man sich bei Fehlern behelfen, einige Kunden bekommen Fehler überhaupt nicht mit da sie die nicht betreffen. Z.B. billige USB Waage übermittelt falsche Werte, da hat man halt ein paar Tage das Gewicht gewogen und im Feld eingegeben.
Oder Kunde hat noch nicht auf DHL 3.0 umgestellt und seine Retouren meldeten einen Fehler, weil die Receiver-ID fehlte. Eingetragen und weiter geht es. Interessanterweise habe ich das, mit Hilfe hier im Forum, noch viel besser umsetzen können.

Grundsätzlich muss ich @Enrico W. in sofern recht geben das JTL nicht alle Möglichkeiten abdecken kann. Wer das verlangt sieht glaube ich die Komplexität der Wawi nicht. Auch gemessen am Preis, natürlich könnte JTL ein paar hundert Leute mehr einstellen,
aber dann bewegen wir uns wohl im 5-stelligen Bereich und sehr wahrscheinlich gibt es momentan gar nicht so viele Kräfte am Markt. Das heißt das Fehler dabei sein können die JTL nicht sehen kann weil sie die Vorgehensweise/Arbeitsweise nicht auf dem Plan haben kann.
Das relativiert auch das abwarten bei neuen Versionen. Gut finde ich auch die Idee mit einer ESR Version wie bei Firefox.

Ich freue mich über die 1.7.9.0 mit den neuen Filtermöglichkeiten, nun auch im Kundenbereich (Sharp-Version), und den Bedingten Formatierung, neben vielen anderen Neuerungen. Kleines Schmankerl das Schloss oberhalb der Kats im Artikelstamm.
Ich denke wir müssen noch bis zur 2.0 durchhalten, da wohl bis dahin die Wawi komplett in 64-bit läuft. Jedes Update wie z,B, 1.8 bringt einen weiteren Bereich nach C# und somit die Vorteile in diesen Bereichen.

Nun hoffe ich das es mal "Likes" für mich und meine aufopferungsvolle Arbeit regnet, ansonsten muss ich ja denken ^"keiner mag mich".