Wie lange wird die 4.10er noch mit Patches versorgt?
Konnte dazu nichts finden.
Danke.
Hallo @sieg01,
es gibt keinen festgelegten Zeitraum. Sobald die 6.1.x als stable erscheint. Vgl. https://oxidforge.org/en/release-plan
Ich werde vermutlich nicht umhinkommen, mich im Laufe des nächsten Jahres nach einer Oxid-Alternative umzusehen.
Bezogen auf die Diskussion hier: Oxid eShop 6 +Composer
könnte ich mir vorstellen, dass 4.10.x noch bis maximal Frühling 2019 unterstützt wird und dann fällt der Vorhang. Evtl. fällt er ja auch schon früher… 
Der Release Plan gibt darĂĽber keine Auskunft.
Ich glaube nicht dass du damit das “Problem” löst. Früher oder späte werden auch andere (PHP)-Shopsysteme diesen Weg verfolgen (müssen?) …
Es geht hier nicht (nur) um mich. Wie im verlinkten Thema zu lesen, bin ich ja nicht der Einzige der vor dem Berg steht und Entscheidungen treffen muĂź.
Eine Migration nimmt man nicht auf die leichte Schulter und auch nicht die Auswahl der möglichen Alternative. Du kannst dich evtl. daran erinnern, dass wir bereits im Frühling 2014 telefonierten.
Die Arbeiten an der Migration hin zu Oxid erfolgte dann im Winter 2015/16.
Wie ich im anderen Thema bereits geschrieben habe - Oxid eShop 6 +Composer
Haben somit Pech gehabt - weil auf’s “falsche Pferd” gesetzt. Sowas nennt sich dann auch: “$hit happens”.
Naja, wenn du jetzt schon auf Oxid bist kannst du ja erstmal die weitere Entwicklung in allen Bereichen abwarten. Zudem wird an dem Tag, an dem der aktive Support für die 4.10.x ausläuft der Shop erstmal weiterlaufen und du hast immer noch Zeit zu reagieren.
Möchte nicht wissen, wieviele Shop noch mit Versionen <= 4.8 am laufen sind.
P.S.: Mir gefällt die Entwicklung mit den komplizierten Responsive-Design Themes auch nicht, da war Basic viel einfacher und übersichtlicher, etc. Trotzdem kommt man heute nicht drum herum, egal wie ich persönlich das nun finde.
cya
Alternativlos? Ich weiß ja nicht. Mir fällt kein Grund ein warum die zwangsweise Verwendung von Composer für den Endanwender notwendig sein sollte. Also nicht für Entwicklung sondern für Installation des Shops, Installation von Extensions und für Shop-Updates.
1 Like
Hatten heute erst wieder ne 4.4 am Tisch 
Ich denke es kommt immer vom Standpunkt aus gesehen an, siehe auch die Continuous * Fraktion im Oxid eShop 6 +Composer - #3 by sieg01 Post.
Und ich wäre so gerne ein netter Kerl… 
Was bitte soll das sein? Ich mache nebenbei gesagt nicht gerne Männchen und mag es gar nicht, wenn ich dazu gezwungen werde.
Muss man sich tatsächlich so ausdrücken, dass dem Rest der Welt seine vermeintliche Dummheit unter die Nase gerieben wird?
Ich persönlich brauche so etwas nicht für mein Selbstwertgefühl…
Nothing for ungood.
Ciao,
Steffen
Betrachte die Plattform doch einfach wertfrei: “Wie meinen?” sollte schon reichen, damit es Dir erklärt wird. “Männchen machen” wäre bestimmt schön anzusehen, musst Du aber nicht .
Es geht darum dass die etwas größeren Agenturen sowieso so arbeiten dass die Umstellung auf Installation per Composer für sie vorteilhaft ist, also zumindest keine Nachteile bringt. Das habe ich scherzhaft continuous* genannt, wegen der bei dieser Art der Entwicklung verwendeten Begriffe continuous integration, continuous delivery, continuous deployment.
[quote=“Firefax, post:7, topic:92655”]
Naja, wenn du jetzt schon auf OXID bist kannst du ja erstmal die weitere Entwicklung in allen Bereichen abwarten. [/quote]
Ja, dass wird schon so werden…
… die Gedanken und Suche starten sukzessive. 
Na so sukzessiv sollte es nicht werden 
Das habe ich bisher ganz auĂźen vor gelassen und dem Anschein nach, habe ich gut daran getan.
Doch habe ich die Hoffnung nicht aufgegeben, dass sich OXID eSales eines “besseren besinnt” und beim “straight forward” bleibt.
Sorry, Du hast schon recht, aber ich bin ggw. etwas dünnhäutig und anstrengend, meine Freundin wird das sicher augenrollend bestätigen…
@leofonic: Oki, danke für die Erklärung! 
Ja ist halt jetzt auch einfach so. Ich sehe da wie schon gesagt auch kein Riesenproblem drin, finds aber aktuell noch etwas hakelig. Vielleicht kann man ja mal sowas wie den Contao-Manager bauen.
Es fehlen halt einfach die Infos für OXID-Nutzer und natürlich auch Best Practices - aber die hat ja OXID anscheinend selber nicht. Die Entscheidung auf composer zu setzen und welche Auswirkungen dies in alle Details hat, ist wohl nicht ganz klar gewesen … und jetzt haben sie (und auch andere) den Salat 
…
1 Like
ich dachte, dass es durch den Umstieg auf Symfony mehr oder weniger erzwungen war.
Also gar nicht direkt die Entscheidung von OXID selbst, höchstens dass man keine Möglichkeit gesucht/gefunden hat, ohne Composer auszukommen
Welcher Umstieg auf Symfony? Hab ich was verpasst?!