Neu JTL Updates mit oft neuen Fehlern

[gnarx]

Als Beispiel:
Die 1.7.8.1 hat gemeldete Fehler die in der 1.7.9 behoben sein sollen. Nun stellt man fest Fehler wurden behoben aber es wurden auch viele neue Sachen eingebaut oder gefixt.
Könnte man nicht das Update der 1.7.8.1 nur Fehlerbereinigen und z.B. 1.7.8.1a nennen? Beim a hinten weiß man dann das die Updateversion nur Fehlerbereinigt ist.

Bitte denkt dran das die Lage nicht so rosig ist und jeder Fehler der u.U. Umsatzverluste einbringt fatal sein kann. Bitte denkt mal mehr an eure Kunden oder versucht euch mehr in die rein zu versetzen.

 

[Enrico W.]

Die 1 am Ende ist schon ein Hinweis auf Fehlerbereinigung. Gab es davor keine passende 0 ist da ein dringender Fehler bereits rechtzeitig gefunden und direkt bereinigt worden.
Die Versionen, deren letzte Ziffer nicht die 0 ist, enthalten damit dann keine neuen Features o.ä. Ausnahme ist die 1, wenn, wie oben geschrieben, keine 0er vorher veröffentlicht wurde.

Oder anders ausgedrückt:

1. x.x.x.0 -> neues Release
2. x.x.x.1 -> Bugfixing
3. x.x.x.2 -> Bugfixing

Zweites Szenario:

1. x.x.x.1 -> neues Release, mit dem auch direkt Bugs gefixt wurden
2. x.x.x.2 wie oben.

 

[gnarx]

Ich nehme das mal so hin, leider haben wir in letzter Zeit nach einem Update immer neue Fehler. Aber danke für deine Antwort.

 

[Enrico W.]

Leider lässt sich das nicht ausschließen, das liegt in der Natur der Sache. Änderungen an einer Software, die so komplex ist, können immer ungewollte Nebeneffekte haben. Wir arbeiten gerade sehr hart daran, eine Struktur aufzubauen, die davon so viel wie nur irgend möglich abfängt. Es dauert nur leider ein bisschen, bis die Basis dafür geschaffen ist und die Aktionen greifen können.
Glaub mir, ich würde auch lieber das Forum aufmachen und sowas lesen wie "Hey, wie kann ich dieses und jenes umsetzen?" mit passenden Antworten statt "hier geht schon wieder was nicht".
Immerhin kann ich die Kundensicht aus diesen Beiträgen mitnehmen und in die neuen Strukturen einfließen lassen.

 

[gnarx]

Hört sich gut an. Du sag mal kann sich da mal jemand drum kümmern: https://forum.jtl-software.de/threads/artikelbilder-die-sehr-hoch-sind-zerreissen-das-layout.201313/

 

[Enrico W.]

Ist ein anderes Thema, die Supporter dieses Bereiches sind aktuell (leider) recht gut beschäftigt. Aber ich stups sie mal an, vieleicht findet mal einer die Zeit, da kurz reinzuschauen.

 

[Stephan K.]

Also dass gestern Nacht (dumm) das Update eingespielt wurde und wir heute morgen mit Staunen fest stellen dürfen, dass der Amazonabgleich zu 100% nicht mehr geht, ist schon ein Paradebeispiel für diesen Thread hier.

Ticket ist schon eröffnet. Ich hoffe der fix kommt genau so schnell mit heißer Nadel (unter 4 Stunden, damit wenigstens etwas Produktivität möglich ist) wie die letzten paar Updates.

Woran liegt es? Irgendwo in irgendeiner Tabelle ist wohl statt einer Zahl ein NULL-Wert, der sich aber nicht in eine Dezimale umstellen lässt und daher - bricht der ganze Abgleich komplett ab.
Bestellungen, Retouren, Rechnungen...

 

[Enrico W.]

@Stephan K. Auch wenn ich Frust und Ärger verstehen kann: Das gehört hier echt nicht zum Thema.
Hier ging es um die Nummerierung, um Fix-Versionen von Release-Versionen mit neuen Features unterscheiden zu können. Ansonsten könnten wir uns ein Forum mit verschiedenen Fachbereichen sparen und machen einfach einen Endlos-Thread, in dem jeder postet, was ihn gerade bedrückt. Niemand steigt da dann noch durch.

 

[Stephan K.]

Naja, entschuldige, Rico, wenn ich " JTL Updates mit oft neuen Fehlern" mit einem live-Beispiel ausschmücke, das nicht nur "Frust und Ärger", sondern Imageverlust und Geldschaden bedeutet.
Da ist die Nummerierung weniger wichtig, wenn es stattdessen ein badge wie "von JTL auf Herz & Nieren geprüft" vor dem Update gibt. Ätsch, bätsch, gibt es aber nicht, da Updates von euch immer mit Fehlern kommen. Auch mit alten, gefixten oder neuen, unerwarteten. Wie fällt es einem automatisierten Testtool nicht auf, wenn ein Wert nicht konvertiert werden kann und deshalb alles abstürzt? So etwas simples?
Könnte ich als Inhalt des Threadtitels ebenso formulieren und würde dann immer noch zum Thema passen.
Themenrelevant entgegen deiner persönlichen Meinung (bitte objektiv und bei der Gesamtheit der Argumente bleiben, sonst kannst du das nicht im Umkehrschluss von anderen erwarten und sie daraufhin wiederholt ansprechen (machst du nicht nur bei mir hier im Forum)).


Ja, auch uns waren die USt-ID Nummern in den Aufträgen wichtig, daher das Update.

Und ich weiß, das wirkt jetzt wieder sehr persönlich, aber: Ich muss meine Zeit jetzt leider anderweitig verplanen. Man kann als Unternehmer nicht ständig im Forum surfen und Meinungen bestätigen oder bugs posten, weil das zu viel Zeit frisst.
JTL Software frisst viel Zeit.
Ob man darüber philosophiert, wie man Updates besser kennzeichnen könnte, damit die Leute - eure Kundschaft - nicht ständig herzhaft auf die Nase fällt...
Dann gehört das in der Laberthread. Denn an eurer Updatepolitik wird sich in nächster Zeit doch kaum was ändern. Sagst du ja selbst: Wir dauern.

Also kann man den Thread auch schließen, da man gegen ne Wand stößt.

 

[Enrico W.]

Ich fürchte, du missverstehst mich. Deine Kritik ist möglicherweise durchaus angebracht - wie gesagt, da kann ich Dein Problem aber echt nicht bewerten.
Nur gehört es nicht in diesen Thread! Der Thread dreht sich schlicht und ergreifend um die Nummerierung.

Ja, die Überschrift lässt viel Interpretationsspielraum, liest man aber den Eingangsthread dazu wird klar, worum es hier erst mal geht.

Wie soll ich Probleme an die Fachbereiche weitergeben, wenn die einfach irgendwo mit reingepostet werden, um Frust loszuwerden? Richtig, es geht nicht. Und ich kann auch nicht alle Fachbereiche in ein Thema schieben, weil da dann elfundachzig User ihre Probleme gesammelt reinposten.

Fazit: Kritik? Klar! Aber nicht wahllos irgendwo sondern mach ein neues Thema im passenden Bereich dazu auf - in Deinem Falle dann am Besten im Bereich Amazon.

 

[mh1]

Leider lässt sich das nicht ausschließen...

Ich bin hier im Forum ganz gewiss nicht angemeldet, um an JTL rumzumeckern.
Aber hier musste ich echt schmunzeln...

, das liegt in der Natur der Sache. Änderungen an einer Software, die so komplex ist, können immer ungewollte Nebeneffekte haben.

klar lassen sich diese Nebeneffekte nicht zu 100% ausschließen und je komplexer das Projekt wird, desto mehr solcher Nebeneffekte werden möglich.

Aber der Satz klingt einfach so ein bisschen nach "da können WIR nichts dafür, denn das ist das natürliche Verhalten bei JEDER Softwareentwicklung"

Man kann ja mit umfangreichen Unit- und Integrationstests bzw. Regressionstests noch vor einem Release ziemlich viel abfangen und mögliche Nebeneffekte schon im Vorfeld erkennen.
Das ist wirklich keine Kritik an JTL. Ich wollte den Satz nur nicht so stehen lassen, denn mir sind sehr komplexe Projekte bekannt, wo vor jedem Release zigtausende Regrsessiontests automatisiert drüberlaufen.

Glaub mir, ich würde auch lieber das Forum aufmachen und sowas lesen wie "Hey, wie kann ich dieses und jenes umsetzen?" mit passenden Antworten statt "hier geht schon wieder was nicht".

Aber diesem Satz kann ich zu 100% zustimmen
ICH würde zusätzlich auch gerne positive Erfahrungen von Anwendern lesen (sowas wie "Hey klasse, gestern wurde die 1.7.blupp veröffentlicht. Hier kann ich jetzt sogar dies und das. Das spart mir soviel Zeit und macht voll Spaß!")

 

[Enrico W.]

Ernsthaft? Bitte keine Rosinen rauspicken sondern den Satz im Zusammenhang mit dem ganzen Beitrag #4 lesen. Ansonsten könnte man alles irgendwie umdeuten.

 

[Nando Hiller]

Also dass gestern Nacht (dumm) das Update eingespielt wurde und wir heute morgen mit Staunen fest stellen dürfen, dass der Amazonabgleich zu 100% nicht mehr geht, ist schon ein Paradebeispiel für diesen Thread hier.

Ticket ist schon eröffnet. Ich hoffe der fix kommt genau so schnell mit heißer Nadel (unter 4 Stunden, damit wenigstens etwas Produktivität möglich ist) wie die letzten paar Updates.

Woran liegt es? Irgendwo in irgendeiner Tabelle ist wohl statt einer Zahl ein NULL-Wert, der sich aber nicht in eine Dezimale umstellen lässt und daher - bricht der ganze Abgleich komplett ab.
Bestellungen, Retouren, Rechnungen...

Wir schauen im IssueTracker, was für Bugs in 1.7.x bekannt sind, um solch eine Situation zu vermeiden, dass der Amazon-Abgleich nicht mehr funktioniert.
Bei unserer Umstellung von 1.5 zu 1.6 war es das gleiche, der Amazon-Abgleich lief nicht mehr.
In den IssueTracker hat es der fehlerhafte Amazon-Abgleich nicht geschafft.
https://issues.jtl-software.de/issues?project=ea&component=16029

 

[MichaelH]

Was wurde eigentlich aus diesem Konzept ?
Gibt es noch ab und zu eine stabile Version und wie erkennt man diese ?

JTL-Wawi Ab sofort erfolgen die Veröffentlichungen unserer Warenwirtschaft in zwei unterschiedlichen Versionen. Ab Version 1.3 von JTL-Wawi finden Kunden auf der Download-Seite unserer Website sowohl einen Release Candidate als auch eine stabile Version vor. Die beiden Downloads unterscheiden sich wie folgt: Release Candidate (RC) Hierbei handelt es sich um die jeweils neuste Veröffentlichung von JTL-Wawi, die auch die aktuellsten Features enthält. Der RC entspricht unseren bisherigen Veröffentlichungen von Produkten, hat also bereits ausgiebige Tests bei Pilotkunden sowie Betaphasen durchlaufen und wurde bereits produktiv eingesetzt. Einige Probleme lassen sich jedoch nur im Einsatz auf einer Vielzahl unterschiedlicher Systeme sowie bei unterschiedlichen Kunden auffinden und beheben. Daher ist ein Release Candidate immer ein Produkt, das sich in einer öffentlichen Testphase befindet, jedoch schon in großen Teilen stabil läuft. 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. Wir möchten unseren Kunden somit die Wahl geben, entweder mit einer intensiv getesteten und somit stabilen Version zu arbeiten oder aber eine größtenteils stabile Version zu nutzen, die alle neuen Features enthält, aber an einigen Stellen noch Probleme verursachen kann.

 

[Enrico W.]

1.7.9.x wäre eine Stable, wenn sie die erste der 1.7.9er ist.
also 1.7.9.0 zum Beispiel. Oder wenn es keine 0er gab, dann die 1.7.9.1 oder 1.7.9.2 - je nach dem, ob noch was gefunden und beseitigt wurde.
Und ja, ich bin mir bewußt, dass Stable nicht immer stable heißt, diese Diskussion können wir also auch lassen. Ärgert uns genauso wie Euch und wir arbeiten dran.

 

[MichaelH]

Nein, die Diskussion kann man nicht lassen, weil - JTL könnte eine Version als Stable deklarieren.
Wann ist ja egal.
Und meine Frage hast du nicht beantwortet - ich hatte gefragt was mit diesem Konzept geschah ?
Wurde das sang- und klanglos heimlich begraben oder halten sich nur die Entwickler nicht daran ?

Denn wenn jemand von 1.5 oder 1.6. oder 1.7.x updaten will, dann sollte er wissen welche aktuelle Version lt. JTL stable ist und es kann nicht jede Woche oder alle 2 Wochen eine stable-Version geben, denn das wäre unglaubwürdig.
Gilt für WAWI und Shop.

Denn wer will schon nach einem aufwändigem Update gleich noch 2, 3 x updaten und ggf. in eine Update-Zwangs-Spirale kommen wegen laufend neuer Fehler.

 

[Enrico W.]

Ähem - ich glaube, da geht lediglich das Begriffsverständnis ein wenig auseinander.
Als Stable gilt das, was raus geht. Dass wir den Releasezyklus hochgeschraubt/geändert haben, spielt da erst mal keine Rolle.
Ich denke, in Deinem Beispiel sollte man eher vom Major Release sprechen, oder?

 

[MichaelH]

Release Candidate (RC)
Stabile Version

Hast du auch das gelesen was ihr "damals" dazu geschrieben habt ?
Ihr könnt RCs raushauen soviel ihr wollt, aber irgendwann solltet ihr eine Version auch als " Stable" bezeichnen.

"Begriffsverständnis" ja, genau, darum geht es, Begriffe werden definiert so wie oben, dann haben auch alle das gleiche "Verständnis".
Die Definition von Qualität: "Ein Hemd mit zu kurzen Ärmeln kann beste Qualität haben, sofern es ein Kurzarmhemd ist."

Und ein System mit 0en, 1ern & Co ist doch uninteressant, wenn ihr schon Begriffe eingeführt habt die man auch versteht.
Stable.

Du aber schreibst "Als Stable gilt das, was raus geht." .... sobald dann die auffälligsten Fehler korrigiert sind oder wie ??? 😂

Natürlich kannst du auch von Major-Release sprechen und was Neues einführen, allerdings habe ich kein Mail dazu erhalten (wie damals wegen Stable), welche die Begriffen definiert.

Konklusio:
Die Entwicklung hat wohl eigenmächtig nicht eingehalten was mal festgelegt wurde ...

 

[Enrico W.]

RCs sind in der Testphase - sprich Open Beta.

 

[MichaelH]

RCs = Testphase = Open Beta

Gut das dies alle wissen und problemlos ihre Stable downloaden in x.x, x.x.x, x.x.y, x.x.y.x und x.x.y.x.x Version bis die dann mal Stable ist.
Ich habe den Eindruck du hast das Konzept von Stable nicht verstanden und was das Ziel von Stable ist.

RC
Der RC entspricht unseren bisherigen Veröffentlichungen von Produkten, hat also bereits ausgiebige Tests bei Pilotkunden sowie Betaphasen durchlaufen und wurde bereits produktiv eingesetzt.

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.