Hallo, vom Gambio Update-Assistent im Kundenportal wird ja ein Update-Paket zum Download angeboten, welches alle notwendigen Updates ab installierter Version enthält und ausführt. Somit wird auf die aktuellste verfügbare Version upgedated. Gibt es eine Möglichkeit, einzustellen, dass das Update-Paket zum Updaten auf die aktuellste STABLE Version (momentan: 3.12.3.0) geschnürt wird und nicht auf die aktuellste überhaupt (momentan: 3.13.3.0)? Es würde die Sache vereinfachen und sicherer machen, als manuell nacheinander die passenden Einzel-Updates zu installieren. Vor allem, wenn man nicht jedes Update mitmacht. Vorschlag: Ein "Schalter" auf der Download-Seite: "aktuellste" oder "aktuellste stable". Wäre das machbar und was haltet ihr davon?
Soweit ich mal irgendwo gelesen habe, geht das nicht. Die stabile Version 3.14.0 müsste aber Anfang September kommen, Wenn du auf der stabilen Ebene bleiben willst, würde ich von MasterUpdate zu MasterUpdate gehen (ist etwa alle 4 Monate ein Update) Die Zwischen-Updates 3.x.1, 3.x.2 und 3.x.3 würde ich nur machen, wenn ich von einem der genannten Probleme betroffen wäre.
Vielen Dank für die Infos, das klingt nach einem guten und gangbaren Weg. Wie ist die Meinung der Entwickler zu der Anregung?
Die meisten Entwickler von Modulen geben Module immer nur für die Masterupdates frei. Alles weitere ist in den meisten Fällen gar nicht zu schaffen, wenn man nicht nur Module testen möchte. Ich empfehle meinen Kunden, deren Shops ich betreue, auch immer nur die Masterupdates zu machen.
Das ist aber vielfach falschen Herangehensweisen der Entwickler geschuldet. 1. Nach einem initialen Featureupdate verändern sich keine Grundfeste mehr, Bugfixing findet aber statt. Das Risiko ist damit relativ normal. 2. Modulentwickler neigen dazu Codeteile zu überladen, die man nicht überlädt, weil das nie stabil ist. Dann kann man manchmal irgendwelche Funktionen nicht machen, ja, aber dann macht man dafür eben kein Modul. Ende, kann keiner.
Ganz schön mutige Ansage, für jemanden der schon seit mindestens 3 Jahren einen neuen Checkout ankündigt und alte Progammfunktionen einfach weiter "aufbohrt" anstatt das die neu gemacht werden (Sonderangebote). Ich kenne hier auch jemanden, der immer wieder sagt man soll das nicht so pauschalisieren, das ist dann Stammtischpolemik. Mal sehen ob Du weißt wen ich meine
Zum Thema altes Zeug aufbohren: Das können wir dann mal machen, wenn der Umfang sehr klein ist. Damit Leute die da auf etwas warten weniger lange auf der Strasse sitzen. Wir würden einen Teufel tun in Altleichen viel zeit zu investieren. Das ist zum Beispiel auch so ein Bereich, den man nicht sinnvoll überladen kann, das wird einfach immer wieder knallen. Wenn wir weiter machen was wir vorhaben auch noch viel mehr als früher. Die Quintessenz ist: Man kann dafür normal keine Module anbieten die was taugen, geht nicht, kann niemand. Sehen wir, ist aber so. Natürlich. Du hast aber eine allgemeine Aussage getroffen, auf die ich fand auf die man gerade mal einigermassen generalisiert antworten konnte. Oft genug geht das gar nicht, das fand ich noch möglich. In diesem Beitrag bin ich auch schon genauer auf ein konkretes Thema gegangen, weil du mir dankbarerweise ein Stöckchen zugeworfen hast.
Ich habe eine einfache Frage relativ einfach beantwortet. Das war aus meiner Sicht nicht zu allgemein, das ist nur die Zusammenfassung von Aussagen, wie man sie hier im Forum des öfteren findet. Ich habe extra auf meistens eingegrenzt, da ich nicht weiß ob ein oder mehrere Entwickler die Module für die Zwischenversionen freigeben. Bei den hier Bekannten Modulentwicklern, die hier im Forum viel Hilfestellung geben, ist es nach meinem Wissen so, dass dort nur die Masterupdates freigegeben werden. Deswegen finde ich diese Aussage inklusive der Aussage über das Testen nicht so allgemein. Wir sollten das hier jetzt aber auch nicht weiter vertiefen, sonst machen wir den Thread hier kaputt und das muss nicht sein. Vielleicht könntest Du ja noch auf die Frage eingehen, zu der ich meine erste Antwort geschrieben hatte.
Unsere Sichtweise ist: Normale Nutzer sollten die aktuellste Version nutzen. Dahin führt der Updateassistent. Nur Leute mit besonderen Stabilitätsbedürfnissen sollten die "gerade Version" benutzen und sich damit zurückfallen lassen, das heisst das ist der Sonderweg. Der Assistent kann nur eins und deckt den normalen Weg ab.
Ich halte das schlichtweg für falsch. "Normale Nutzer" sind diejenigen, die einen möglichst stabilen Shop erwarten, weil sie damit täglich arbeiten und damit Geld verdienen wollen. Diese Nutzer vertrauen darauf, dass von Drittanbietern gekaufte Module funktionieren. Dies ist im exeperimentellen Zweig allerdings definitiv nicht der Fall. Gambio lockt unerfahrene Nutzer genau in diese experimentellen und tendenziell unsicheren Versions-Zweig.
Wenn ich Fremdmodule installiert habe und update auf eine vom Modulanbieter nicht supportete Gambio-Version, habe ich als Normaluser echte Probleme. Kein Support im Falle daß es klemmt. Das kann nicht Sinn der Sache sein. Wäre es wirklich ein so großes Problem ein Updatepaket auf die jeweils höchste stabile Version anzubieten?
Wir halten unsere Featurestränge nicht für instabil, dann würden wir Beta dranschreiben, das ist aber was anderes. Die Leute haben ausserdem was davon, wenn Sie die neuen Sachen auch nutzen können. Der andere Branch heisst auch nicht "stabil" sondern "maximal stabil". Dazu gilt sogar auch: Es gibt immer auch bekannte aber ungefixte Bugs in den Stable-Strängen. Wenn der Fix für ein Problem vorliegt, aber zu invasiv für einen Backport ist (wir arbeiten immer auf den aktuellen Strängen und portieren dann eventuell herunter auf alt) und die Wichtigkeit einer Lösung als zu gering eingestuft wird, dann kriegt den jemand in einer stable Version nicht und muss warten. Das im wesentlichen ne Macke der Drittanbieter, die sich denke ich mit Fortgang des Appstore Projekts lösen wird. Es gibt bislang nur grobe Pläne welchen Regeln Autoren da befolgen müssen, aber wir werden zum Beispiel eher keine Module aufnehmen, die nicht für aktuelle Versionen des Shops vorliegen. Wir werden in Zukunft auch die Cloudshops schrittweise näher an unseren wirklich "Head" bringen, die Spitze der Entwicklung, spätestens dann wirds ein muss. Das geht mit etwas Vorbereitung und ein paar Regeln mit ziemlich ruhigem Gewissen. Derzeit folgen die Cloudshops noch dem max-stable-Branch, das nervt. Der nächste Schritt wird vermutlich das wir die immer wenn das zweite SP einer Featurereihe kommt (x.[ungerade].2.0) kommt auf diese Version updaten, um da weniger unnötige Zeit zu verlieren und Agilität für die Cloudleute zu gewinnen. Experimentell ist das falsche Wort. Die echten Experimente finden bei uns vor Release statt. Nach Release sehen wir normal eher die Kleinigkeiten. Wir wollen, das Nutzer den neuesten Stand nutzen können. Das ist für die meisten schlicht die richtige Wahl. Über ne Klippe springen ist ganz was anderes. Nee, wie gesagt, den Modulentwicklern werden wir uns auch noch mit neuen Botschaften zuwenden. Die halten manchmal falsche Dinge für wahr, darum müssen wir uns kümmern. Nochmal: Es ist nicht gewollt, weil wir das grösste natürliche Interesse der meisten Kunden auf der neuesten veröffentlichten Version sehen, die kleinen Hindernisse sind weiter zu minimieren.
Ich denke mal, die zeitliche Komponente ist für die Modulentwickler der Hauptgrund die ungeraden Versionen zu überspringen. Je mehr Module angeboten werden, desto mehr Zeit benötigt man für die Pflege. Die Limitierung auf maximal stabile Versionen verdoppelt schlichtweg das Zeitfenster und halbiert den Arbeitsaufwand für Tests.
Die zeitliche Komponente gibts kaum. Die grossen Plattformänderungen kommen immer mit einer x.[ungerade].1.0, danach wirds schnell sehr viel ruhiger. Die Modulentwickler verschieben nur die nötigen Anpassungen nach hinten,der zeitliche Abstand der Anpassungsintervalle bleibt gleich. Falsch.
Ich denke, dass das Problem mit den Feature-Versionen und Drittanbietern sich nach und nach lösen wird, wenn die Module die Shopdateien nur noch geringfügig streifen, als diese komplett zu nutzen. Das geht aber noch nicht überall. Es ist blöd für einen Entwickler, wenn er Modul A auch für die ungerade Reihe anbietet, Modul B aber nur für die Gerade. Also bleibt er generell auf der geraden Linie. Wenn man Fremdmodule nutzt, springt man eben von Master-Update zu Master-Update. Dafür braucht man kein Paket. Und wer ein Fremdmodul nutzt, wird eher weniger von einer Version 3.8 oder so auf eine 3.12.3 springen wollen. Der wird dann doch eher auf die 3.14 warten (die es dann ja auch als Paket gibt).
Für Module im Appstore werden wir zum Beispiel einen Review Prozess einrichten müssen, bei dem wir den Code prüfen. Einerseits auf Best Practices, dann auf Codequalität, dann auch auf Zukunftsfähigkeit. Wenn uns irgendwas davon grosse Sorgen macht, werden wir das ohne Nacharbeit nicht aufnehmen können. Dabei wird auch herauskommen, dass wir bei manchen Sachen erstmal Nein sagen, zum Schutz der Nutzer und um andere Versprechen an die Nutzer zu wahren. Das eine ist dann aber, dass wir Bedürfnisse erkennen werden, das andere dass Regeln überhaupt mal gut sind und es dann welche geben wird..
Wie soll das denn funktionieren? Habt Ihr noch ein paar Programmierer in der Schublade gefunden oder sind die Tage verlängert worden? Ihr kommt jetzt schon teilweise nicht mit dem Arbeitsaufkommen zurecht, es werden immer wieder Sachen nach hinten geschoben und jetzt wollt Ihr auch noch den Code der Modulentwickler prüfen. Wie lange sollen die Entwickler denn auf die Freigabe warten? Nach meinen Informationen habt Ihr im Augenblick keine freien Kapazitäten um Entwicklungen von Kunden auszuführen, also wer soll dann wann den Code prüfen? Den Gedanken mit der Zukunftsfähigkeit finde ich prima, aber ich vermute mal, dass unsere Ansichten da etwas auseinander gehen. Aus meiner Sicht können die Modul-Entwickler nur zukunftsfähig programmieren, wenn sie die Zukunft kennen. Das setzt allerdings voraus, dass die Entwickler rechtzeitig von Gambio informiert werden und nicht vor vollendete Tatsachen, wie bei den Themes, gestellt werden.
Wow, was für eine Diskussion auf meine "einfache" Frage hin. Ich glaube, es gibt einfach verschiedene Sichtweisen, und der User sollte entscheiden könnte, ob er mit den Update-Paketen die "stable"-Schiene fahren möchte oder die fortschrittlichere mit neuen Features. Es gib viele - sorry - "Schmalspur"-User, die nicht so tief drin stecken in der Materie und sich einfach nur einen maximal stabilen Shop wünschen. Dies impliziert die "stable"-Schiene. Andere möchten schnell alle neuen Funktionen nutzen können, auf die sie schon lange gewartet haben. Beides völlig gleichberechtigt, und mit den Masterupdates auch machbar. Aber trotzdem wartet manch einer aus verschiedensten und sicher auch individuell berechtigten Gründen länger mit dem Update. Daher nochmal meine Frage an die Entwickler: Ist es ein großer Aufwand, eine Auswahlmöglichkeit für beide einzubauen? Dann würden sich solche Diskussionen erübrigen und "jedem" wäre gedient...? Danke in die Runde!
Im Moment dauert eine Prüfung eines Moduls etwa 2-7 Tage nach Einreichung. Das machen wir jetzt nämlich auch schon für diverse Anbieter, die uns ihre Sachen mal reinreichen. Die Leute die Individualaufträge ausführen sind eine andere interne Abteilung, das hat nichts miteinander zu tun, bietet also keinen Rückschluss auf Kapazitäten woanders. Wir müssen regelmässigt einfach mal Sachen machen und durchziehen. Als wir das mit den Themes gemacht haben, haben wir uns vorher auch Feedback von einigen Agenturen geholt und gefragt was anders werden muss und was nervt, das haben wir dann in Code gegossen. Wir fragen nur nicht jeden vor allem, dann gehts nicht mehr voran, das ist nicht zielführend. Sorry, das hat Nebenkriegsschauplätze aufgemacht, ja... Man musste aber im Prinzip hier nicht nur dir antworten, sondern auch Modulentwickler, die wir auf einen Pfad bewegen wollen. Wenn man denen nicht ab und zu mal sagt "da wirds langgehen", dann sagen die hinterher Sie haben von nicht gewusst und werden vor vollendete Tatsachen gestellt, da muss man manchmal klare Nachrichten senden Es ist regelmässig unser Job in die Zukunft zu denken, Wünsche zu erkennen, Marktbewegungen zu erkennen, Trends vorauszusehen, Tragfähigkeiten auszuloten, die komplette Palette. Genauso kennen wir unsere User vergleichsweise gut: wir lesen viel, telefonieren und mailen viel, haben aus verschiedenen Händlerschichten ein paar Kandidaten auf Kurzwahltasten, wir schauen was anderen machen, was Dienstleister wollen, wo der Gesetzgeber hinrennt... Wir wissen daher auch, wo sich viele Leute unnötig auf für Sie falsch Pfade begeben. Es gibt zum Beispiel ein paar Schalter im Backend, die sollte man nie anschalten. Da kann man dann Warnungen dranschreiben wie man will, die Leute machens trotzdem. Wenn wir wissen, dass Gelegenheit oft genug Blödsinn anrichtet, dann müssen wir im Gemeininteresse gegensteuern. Das kann man auf viele Weisen ganz einfach tun, zum Beispiel in dem man den Leuten die für Sie im allgemeinen richtigen Pakete deutlich vor die Nase hält. Die sind trotzdem richtig auf dem Featurezweig, der Lösungen oft früher erhält. Das wäre grösserer Aufwand, das kann die Portalsoftware nicht. Das könnten wir inhouse umbauen, aber wir sehen die Rechtfertigung und den ehrlichen Nutzen gerade nicht. Die Nachricht die wir verbreiten möchten, können wir - Stand heute - gut verbreiten.