[QUOTE=Thorsten Albrecht;49470]Mit “kontrolliert live” meinst Du, die selben Updates, die in die Testumgebung eingespielt wurden, nochmal am Livesystem einspielen? Oder aber das upgedatete Testsystem zum Liveshop befördern, d.h. einfach die Datenbank umbiegen?
BTW Um später Vergleichsmöglichkeiten zu haben, empfiehlt es sich, den alten Shop ebenfalls noch als (zweite) Testumgebung zu sichern.[/QUOTE]
letzteres, erst auf einem getrennten system testen und dann überspielen.
[QUOTE=csimon;49473]letzteres, erst auf einem getrennten system testen und dann überspielen.[/QUOTE]
Mache ich auch so; ist vmtl. der sicherste Weg. Geänderte Moduldefinitionen und geänderte Bildverzeichnisse (sofern der Kunde auf dem Liveshop weitergearbeitet hat) muss man dann noch separat nachziehen.
[QUOTE=laramarco;49337]es gibt für diese copy paste tätigkeit AUCH user, die dienstleister dafür bezahlen.
sind zwar nur minuten für dich, aber für UNS kostet jeder handgriff der unnötig/unsinnig/nichtplausibel ist - GELD[/QUOTE]
Da hilft nur: nicht updaten. Dann kostet es auch nichts. 
BTW Schön sind auch die Dominoeffekte, die beim Updaten entstehen. Z.B. Shop von 4.20 auf 4.45 upgedatet, und schon funktionieren sämtliche Payment-Module nicht mehr, die dann alle einzeln angefordert und neu installiert werden müssen.
sonst machts ja keinen Spass… 
[QUOTE=Hebsacker;49468]ist doch da unten in der Leiste?[/QUOTE]
Ich mein ja nicht für das Forum generell, sondern für jeden einzelnen Beitrag. 
Obwohl wir dann sicher mit Thorsten Ärger bekommen.
Da tuts ja dann evtl. ein neuer smilie “Thumbs Up”
Oder den Karma-Knopf verwenden!
[QUOTE=Thorsten Albrecht;49475]Da hilft nur: nicht updaten. Dann kostet es auch nichts.
BTW Schön sind auch die Dominoeffekte, die beim Updaten entstehen. Z.B. Shop von 4.20 auf 4.45 upgedatet, und schon funktionieren sämtliche Payment-Module nicht mehr, die dann alle einzeln angefordert und neu installiert werden müssen.[/QUOTE]
nicht updaten und dann die sicherheitslecks :eek:
bin halt immer noch dafür und glaub das sind die meisten - weniger updates und diese auch kontrollierter, also weniger bugs. erspart uns alle kosten und oxid den frust der kunden.
denn solang die wv kunden noch die wartungsgebühren bezahlen, kann auch die bilanz bei oxid stimmen, von nur ce leuts kommt nämlich da nix rein in die kasse.
Ich denke die CE-ler kann man auch ein wenig zur Deckungstbeitrags-Zahlung heranziehen…
Mir geht´s zumindest so, ich wäre nicht böse, wenn OXID verschiedene Funktionalitäten selbst als Module / Erweiterungen anbietet, die dann eben kostenpflichtig sind.
http://www.oxid-esales.com/forum/showthread.php?p=48860#post48625
ich hab nicht die modulwelt angesprochen sondern lediglich die wartungsverträge, denn die setzen voraus, daß eine lizenz verkauft wurde und somit eben die folgezahlungen gesichert sind.
diese zahl ich aber nur dann, wenn ich von einem produkt überzeugt bin und das kann ich nur dann, wenn mir die kosten nicht übern kopf wachsen.
ich bin lang genug dabei um zu sagen, daß die versprechungen zu verbesserungen immer aus dem marketing komment, und dann von der technik nicht eingehalten werden können.
Ja - Nein
Ich meinte, mit einer Änderung in der Vertriebspolitik könnte man auch Entwicklungskosten über CE-Erweiterungen abdecken, und zugunsten einer besseren Arbeit einsetzen.
Hallo,
bin halt immer noch dafür und glaub das sind die meisten - weniger updates und diese auch kontrollierter, also weniger bugs. erspart uns alle kosten und oxid den frust der kunden.
Ich hatte es in diesem Blogpost bereits angekündigt:
http://www.oxid-esales.com/en/news/blog/introducing-beta-tests-and-changing-update-cycles
Vielleicht nochmal zur Info: Es gibt Patches (Änderung der dritten Stelle in der Versionsnummer, z.B. 4.4.6) und Updates (Änderung der zweiten Stelle in der Versionsnummer, z.B. 4.5.0)
Bei Patches werden in aller Regel nur Bugfixes ausgeliefert. Patches passieren monatlich, meist am letzten Dienstag/Mittwoch. Änderungen am Frontend oder gar in der Datenbankstruktur sollten hier in den seltensten Fällen zu erwarten sein, es sei denn, es lässt sich nicht vermeiden. Dann gibt es in der Regel vorab eine Ansage an die Entwickler über die Mailingliste.
Updates enthalten neue Features, die natürlich neue Bugs enthalten können. Ehemals war es so, dass aller drei Monate ein neues Update mit neuen Features rauskam. Das wurde geändert auf alle vier Monate; außerdem wurde eine Beta-Phase dazwischen geschoben (siehe Blogpost). Diese festen Zyklen lassen sich eigentlich ganz gut kalkulieren, sind aber manchmal, wenn es sich um größere Änderungen handelt wie jetzt mit der 4.5.0, nicht immer einhaltbar.
Ich hoffe, das macht es etwas verständlicher.
Gruß
sehe ich genau so
Moin,
ich habe gerade erst gesehen, das dieser Punkt (Patch 4.4.6) hier hinreichend diskutiert wurde, und wollte mich kurz mal anschließen mit meiner Meinung, nachdem ich mich kürzlich erst wunderte und dann auch ärgerte. Ich dachte nämlich, ich bin mal schlau, und packe meinen lokalen Entwicklungsserver in ein svn-Repository, damit ich besser im Blick haben kann, was wo geändert wird/wurde. Und dann kommt dieses Copyright-Update-Pack, ähem! :mad:
Also auch meine unbedingte Bitte für die Zukunft: das Copyright-Jahr irgendwie auslagern und die cust_lang + functions in Ruhe lassen! Was nützt das schönste Template-Overriding, wenn ich doch wieder alles “händisch” auf Kompatibilität prüfen muss?
Nun denn, wurde ja bereits alles gesagt und beantwortet, und abgesehen davon bin ich ziemlich zufrieden mit den Cumulative Packages! Wenn es denn nur max. einmal im Jahr zu solchen Problemen kommt, dann kann da notfalls auch noch mit leben…