Diskussion: Ein paar Fakten zum Trunk (Entwicklerversion)

[Tomcraft]

Ihr wisst ja nun alle, dass wir sehr transparent entwickeln und der Link zum Trac-Environment ist ja auch mehrfach genannt worden.
Es schleicht sich nur langsam bei mir das Gefühl ein, dass ihr alle der Meinung seit, den Trunk produktiv benutzen zu müssen, daher hier mal ein paar Fakten:

- Trunk = Entwicklerversion = unsere Spielwiese!
-> Nicht alles, was im Trunk landet wird zwangsläufig in der neuen Version enthalten sein. Wir entwickeln zwar sehr gewissenhaft und haben auch als Ziel den Trunk zur 1.03 werden zu lassen, aber es kann sich immer mal ein Fehler einschleichen.

- Es kommen öfters Datenbank-Updates mit in den Trunk, die es erforderlich machen, dass eine update.sql ausgeführt wird, das klappt nur ein einziges Mal, danach gibt es Fehlermeldungen, dass die Tabelle schon vorhanden ist.

- Es wird für den Trunk niemals Update-Packs geben! Der Aufwand wäre gigantisch, weil wir quasi für jede einzelne Revision ein Update-Pack bereit stellen müssten.

- Trotzdem suchen wir natürlich Tester, die sich regelmäßig mal den Trunk anschauen und prüfen, ob z.B. die Installation funktioniert. Trotzdem bitte nicht produktiv einsetzen, ihr unterstützt durch das Testen die Community.

Grüße

Torsten



Linkback: https://www.modified-shop.org/forum/index.php?topic=2565.0

[sgei]

Hallo Tomcraft,

wie ist denn die Downloadversion branches_modified eCommerce Shopsoftware-stable-1.0x-r491 zu werten?

Da die Entwicklung der modified eCommerce Shopsoftware Shopversion ständig weiter geht, bieten wir Ihnen hier die Möglichkeit die letzte stabile Version (momentan 1.02) inklusive der letzten Updates zu laden. Diese Version wird von uns als stabil veröffentlicht!

Download modified eCommerce Shopsoftware Version V1.0x inkl. der letzten Updates ( exkl. SSEQ-LIB v0.8 )

Ich habe für den Umzug eines alten xtc 3.04 SP2.1 auf die modified eCommerce Shopsoftware diese Version genommen.

Irgendwie ist die Downloadseite etwas verwirrend.

Steffen

[Tomcraft]

Der Branch kann natürlich eingesetzt werden und kann auch mit den ganz normale Update-Packs aktualisiert werden. Es wird dann zwar durch das Update-Pack, welches auf dem letzten Release-Tag besteht, mehr aktualisiert als nötig, da die fixes ja teilweise schon enthalten sind, aber das ist ja kein Problem.

Der Branch wird nicht mit neuen Features ausgestattet sondern nur um Fehler bereinigt, daher ist nach einem Update die entsprechende update.sql einmalig auszuführen.

Grüße

Torsten

[speedy]

- Es kommen öfters Datenbank-Updates mit in den Trunk, die es erforderlich machen, dass eine update.sql ausgeführt wird, das klappt nur ein einziges Mal, danach gibt es Fehlermeldungen, dass die Tabelle schon vorhanden ist.

Aus diesem Grund wäre meiner Meinung nach auch ein anderer Weg besser.
Man installiert immer die aktuelle DB-Struktur in eine leere Datenbank und importiert die alten Daten. Dies sollte dann am Besten mit dem Installer als "Upgrade" laufen.
Es muss dann nur jeder ggf. seine SQL-Dateien aus den Mods neu ausführen.

Dann wäre auch das Update aus egal welcher Trunk Version auch immer, kein Problem.
Zugleich wäre es eine Upgrade-Möglichkeit von Original-xtc oder beliebigen Forks, die sich an die xtcommerce Standard-DB halten. Denke mal, dass viele deswegen auch nicht umsteigen.

Der Austausch von ggf. fehlerhaften Dateien ist ja kein Problem. Das Problem ist immer nur die Datenbank.

Das mit dem Testen sagt sich immer so einfach.
Der Grund warum viele es produktiv einsetzen ist einfach, weil man nur so im praktischen Gebrauch, Fehler findet.
Alle machen das hier so nebenbei und ich glaub nicht, dass jemand die Zeit hat so aus Spass immer wieder Neuinstallationen mit diversen Trunk-Versionen zu machen und dort von A-Z alles einzurichten und durchzutesten. Das geht nur in nem Live-Shop vernünftig.

Ich habe Vertrauen darauf, dass die Praxis beibehalten wird, dass nur intensiv getestetes in den Trunk kommt, wie es bisher war (Stichwort Bastelecke -> Modulecke) und dann kann nicht mehr viel schiefgehen.
Außerdem sehe zumindest ich mir mit Beyond Compare die Dateiänderungen an und importiere auch die Update.sql nicht blind.

[Tomcraft]

Ich habe Vertrauen darauf, dass die Praxis beibehalten wird, dass nur intensiv getestetes in den Trunk kommt, wie es bisher war (Stichwort Bastelecke -> Modulecke) und dann kann nicht mehr viel schiefgehen.

Das ist aber nicht so... das wäre Wunschdenken. Wie dir sicherlich schon aufgefallen ist haben wir ziemlich oft bugfixes für bestimmte Revisionen, das bleibt einfach nicht aus!

Sieht dann meist so aus -> "bugfix on r4xx", das heisst, bei r4xx ist was schief gelaufen und wurde in einer neuen Revision behoben.

Grüße

Torsten

[speedy]

Jo Torsten,

aber sowas wie z.B. zuletzt falsche Definitionen in den Language-Files kann ich mir auch mit jedem Modul einfangen.
Mir ist schon klar, das du einfach zur Vorsicht mahnen willst. Aber nur selten wird gleich der ganze Shop lahmliegen, das Risiko kann man oft eingehen.

Es bleibt nur:
- Änderungen per Dateivergleich einbinden, so fällt einiges auf.
- nicht unbedingt immer den letzten Trunk einbinden, wenn große Veränderungen stattfanden, also nicht nur Kosmetik - sondern einfach mal 1-2 Wochen warten und dann wieder nachziehen.
- Ich guck mir zumindest immer wieder an, was geändert wurde, bevor ich überlege es zu übernehmen oder zu warten.

Es ist einfach immer wieder das Problem, dass man auf vieles nicht 4-5 Monate warten kann und manchmal auch nicht will, keiner hier wird 2000 Jahre alt. Es sind einfach immer wieder Highlights dabei, die manchmal wie wir gesehen haben, dann auch nur mit dem aktuellen Trunk fehlerfrei laufen.

Ich zumindest bereue es, früher immer n halbes Jahr auf jedes Upgrade gewartet zu haben und ggf. Projekte hinausgeschoben zu haben. Nichts ist schlimmer als der Zeit hinterherzurennen und dann hat sich oftmals das Thema auch schon erledigt, weil andere schneller waren.

Deshalb auch wieder meine alte Anregung, künftig lieber kürzere Update-Zyklen mit kleineren Veränderungen und nicht immer so Hammer-Dinger rausbringen, die den halben Shop umkrempeln.

Ich hoffe, dass Ihr euch das mit der DB mal überlegt, ob das nicht anders besser wäre und ob es so realisierbar ist.
Ist ja auch nicht ganz unüblich, z.B. gibt es sowas bei Foren und geht dann gleich auch in die Richtung Cross-Update.
Ich kann mir noch einigermaßen selbst helfen, andere - auch Umsteiger nicht unbedingt und lassen es dann einfach oder stellen immer wieder die gleichen Fragen im Forum. Einige davon geben mit Sicherheit dann auch irgendwann genervt auf, wenn hier nicht jemand alles haargenau im Forum vorkaut, weil einfach das Wissen fehlt die Tipps umzusetzen. Das würde sich alles damit erledigen.

[Tomcraft]

Hi Speedy, es geht hier in dem Thema nicht darum, wie man es doch schaffen kann den Trunk auch produktiv einzusetzen, wenn man das nötige Wissen hat und einem auch Programme wie WinMerge, Notepad++, phpMyAdmin, MySqlDumper kein Fremdwort sind.

Es geht darum, dass wir uns dahingehend absichern, dass niemand sagen kann "Aber ihr habt doch gesagt, ich soll den Trunk einsetzen und nun funktioniert nichts mehr.". Dem ist nämlich nicht so, der Trunk inst und bleibt als "unstable" deklariert und sollte nicht produktiv eingesetzt werden.

Ich weiss, dass du, gerade bei diesem Thema sehr diskussionsfreudig bist, aber ich rücke da auch nicht nur einen Zentimeter von meiner Meinung ab, lass uns also bitte keine Grundsatzdiskussion darüber führen, wie wir den Shop entwickeln.

Beitrag 1 bleibt so stehen, wie er ist.

Grüße

Torsten

[speedy]

Ich weiß worum es im Thread geht, mit den Tipps sensibilisiere ich doch die User nur noch weiter. Wenn man nicht alles blind übernimmt, fallen mehr Fehler auf und man läuft weniger Gefahr sich Fehler einzufangen.
Man muss auch nicht jeden Tag den aktuellen Trunk übernehmen und schon gleich gar nicht dann, wenn wie zuletzt bei den Zahlungsmodulen mal kräftig in der Schüssel gerührt wurde

Also Ihr müsst Euch dann aber schon entscheiden.
Sollen mehr testen oder nicht.
Fehler kommen dann weiter peu à peu oder wollt Ihr nach der Herausgabe einer neuen Version überrannt werden ?
Reine Beta-Tester denke ich mal, habe wir noch keinen einzigen.
Alle Tester, testen es Live, da man so am ehesten alle Eventualitäten durchgehen kann.

An dem DB-Problem kann man normal was ändern, das können andere Projekte ja auch - zugleich kann man so Usern anderer xtc-Versionen den Umstieg schmackhaft machen, da es dann nicht einfacher gehen könnte.
Ich weiß nicht, ob die Idee überhaupt richtig ankam. Ich meine nicht für jede Trunk-Version irgendwelche Update-Packs. Es ist ein ganzheitlicher Ansatz, egal von welcher Version man kommt.

[Tomcraft]

Mensch speedy, es geht mir doch wirklich nur um eine Absicherung!

Daher schreibe ich weiterhin, der Trunk wird nicht unterstützt, es wird keinen Support geben, es wird keine Update-Packs geben, etc.

Wen willst du denn sensibilisieren? Den User, der eh nicht weiss, wie er mit den angesprochenen Programmen umgeht oder den erfahrenen Benutzer?!

Typ 1.) Liesst sich Beitrag 1 durch und lässt die Finger weg vom Trunk -> Ziel erreicht!
Typ 2.) Denkt sich, was will der Spinner? Geht doch alles, wenn ich nur jedes mal umsichtig mit WinMerge die Änderungen nachverfolge.

Worüber reden wir hier also? Kostet mich nur wieder Zeit, die am Ende des Tages fehlt...

Daher bereinige ich das Thema nachher auch und schliesse es.

[speedy]

Die Absicherung hast du ja jetzt mit Post 1, torsten.
Den Rest liest ja keiner ?

Ich sag ja nicht, Leute installiert alle den Trunk und sag auch nicht du sollst umdenken und es allen empfehlen, sondern wenn dann so ...
Zu den Typen, wie immer gibt es nicht nur zwei Klassen (ala arm / reich), sondern viel dazwischen.

Alle die weiterlesen, wissen worauf sie aufpassen müssen und wie man am Besten den Trunk übernimmt - am Besten mit Dateivergleich-Software wie Beyond Compare.
Auch wissen Sie, dass man man nicht alles blind übernehmen soll, sondern sich auch mal die Changelogs ansehen oder direkt die Änderungen in den Dateien, wenn man das beurteilen kann.

Was mir jetzt wichtig @worüber reden wir.
Nicht immer auf Durchzug schalten, wenn andere neue - wenn auch evtl. einschneidene Ideen haben, nur weil das auf den ersten Blick nach Mehraufwand aussieht. So ist mein Gefühl, weist du.
Die DB-Upgrade-Idee per Installer ist eine Chance und kein Freibrief für alle den Trunk einzusetzen.
Ich fände das wäre auch mal ein paar Worte und etwas Zeit Wert das oder Ideen in dieser Richtung zu besprechen. Ich sehe da große Chancen und letztendlich Arbeitserleichterung für alle. Weniger Support in der Hinsicht und vor allem ziehen wir, wenn das Projekt "modified eCommerce Shopsoftware" ansonsten interessant bleibt, so die User leichter aus anderen Projekten ab.

Und das mit den Update-Zyklen magst du ja auch gar nicht hören, bekomme dazu auch selten antworten wie @DB  . Die Ideen sind ja nicht ganz neu von mir.
Ich sage ja nicht das gleiche was jetzt zwischen 1.02 und 1.03 steckt in 2 Monaten statt 5 Monaten, sondern weniger, dafür öfter.
Man kann so auch besser den Überblick behalten... und mögliche Eventualitäten, die beim Upgrade wichtig sind nicht übersehen.

Fände es schade, wenn das Thema bereinigt wird, denn meine Zeit ist auch nicht umsonst.
Ich opfere oft Zeit vergebens hier, weil man Ideen nicht mal mit Bemerkerungen dazu würdigt, sondern komplett übergeht. Oder Fixes, irgendwo lagern - obwohl andere Kosmetik gemacht wird.
Wenn ich wollte könnte ich auch immer nur zu neuen Versionen aufspringen und dafür mehr Zeit für Studium und Jobben haben.

[Tomcraft]

Ich schalte nicht auf Durchzug, ich versuche nur verständlich zu machen, dass es NIEMALS ein Update für den Trunk geben wird. Jede Energie, die wir dort hinein investieren geht uns an anderer Stelle verloren, genau wie mir Zeit flöten geht durch die Diskussion mit dir darüber.

Das kann einem echt die Lust nehmen, darüber immer und immer wieder zu diskutieren!

Ich klinke mich an dieser Stelle auch komplett aus dem Thema aus. Was ich dazu zu sagen hatte, hab ich gesagt. Thema wir nicht bereinigt, hab die Fixierung aufgehoben und eine neues Thema eröffnet mit altem Inhalt.

Grüße

Torsten

[speedy]

Und das nimmt mir die Lust hier mitzuwirken, wenn alle wesentlichen Ideen "überlesen" werden, nur weil der Fahrplan gerade anders aussieht.
Mit Kosmetik gewinnt man keinen Blumentopf, wenn was aus dem Projekt werden soll, dann muss man mutige Schritte gehen, wie man Sie auch bei anderen Projekten immer wieder sieht. Und dann muss man auch mal ein offenes Ohr für Ideen anderer haben. Ich habe auch nicht in allen Punkten die besten Ideen und höre mir anderes an. Nicht selten, fliesen verschiedene Ansätze in das Endergebnis ein.

Den Eindruck hab ich aber leider immer wieder mit Durchzug, da die Antworten immer wieder um den ersten Post kreisen und keine Bemerkungen zum Rest. Der Sinn ist klar und abgehandelt, meine Bemerkungen gingen dann nen Schritt weiter.
Visionen, wenn du so willst, die ich leider nicht in der Hand habe.
Bin ja nicht der einzige Mensch mit solchen Ideen, fanden andere ja auch schon gut hier.

Du hast, sorry, glaub ich nicht die Idee verstanden.
Es geht nicht um Update-Packs auf Basis von Trunks.
Mit meiner Idee, wenn umsetzbar (müsste web28 beurteilen können), würde die Version keine Rolle spielen. Ob nun ein Trunk, die 1.0, die 1.1 oder sonstige xtc-Versionen mit gleicher Datenbank-Basis.
Es müssen nur die Inhalte aus den richtigen Feldern der DB übernommen werden.
Da immer nur etwas dazukommt und nicht wegfällt oder umbenannt wird, sollte das doch gehen.
Ein einziges DB-Upgrade-Installer-Skript und nicht dutzende, verwendbar für alle xtc-Versionen die die gleiche DB-Basis haben.
Es ist ein Mehrwert mit erstaunlichen Möglichkeiten und nicht etwas um dich zu ärgern.

P.S.
Leute, die nen Schritt weiterdenken, werden oft als Spinner bezeichnet, war vor 200 Jahren nicht anders @oben. Hab kein Problem damit, nicht gerade ne hohle Nuß zu sein, die immer nur macht was ihr gesagt wird.

P.P.S.
Ohne es negativ in Hinsicht auf dieses Projekt zu meinen.
Warum empfehle ich niemals 4-5 Monate auf neue Versionen zu warten.
Niemand kann sagen, ob in 4-5 Monaten wirklich was neues rauskommt oder das Projekt vorher schon eingestellt wird. Dann war alles warten umsonst und schnell ist wieder ein Lebensjahr rum.
Ich bin jetzt schon viele Jahre in diversen Opensource-Geschichten dabei und hab einiges erlebt, ob nun Shops, CMS oder Foren. Ob als User oder als Beta-Tester.
Alles ist möglich und die Konkurrenz oftmals schneller als einem lieb ist und schon ist das Aus Nahe.
Deshalb ist mir ein Trunk, an dem ich fixen muss lieber, als 5 Monate in den Sand gesetzt und Projekte verschoben.

[Elmar]

hi zusammen,

ich hae vor, mich bei den tests zu beteiligen. das bringt für mich den vorteil, wenn ich getestet habe, weiss ich was ich installiere.

ich möchte zum testen wie folgt vorgehen:
ich installiere mit xampp auf einen USB-Stick und will dann ddn aktuellen trunk dort installieren.

neben den tests des trunk, will ich dann auch das design der xtc5 etwas für mich anpassen. (das lilla ist schon sehr gewöhnungsbedürftig) erinnert mich an einen bestatter.

ich will zukünftige kunden nicht mit tests im aktiven shop erschrecken. ich muss ja auch von was leben.

ist das mit xampp ein guter weg, oder hat wer was besseres auf lager?
ich denke ich werde täglich ca 1-2 std. in die zukunft inverstieren und so auch versuchen meinen kunden mehr service online bieten zu können.

mir wäre das zu riskant die testerei in einem aktiven shop durch zuführen.
besonders mit den erlebnissen mit strato!

lg elmar

[Tomcraft]

Du holst nur immer soooo weit aus und für mich ist das dann einfach offtopic.

Updater ist in Planung... Trotzdem wird es kein Update vom Trunk geben, weil wir nicht für jeden Trunk eine Versionsnummer in der Tabelle "database_version" setzen werden.

Gehört hier aber alles nicht mehr ins Thema und liegt in ferner Zukunft.

[speedy]

moah, ich weiß echt nicht, wie ich es besser erklären soll.
Man zieht z.B. alle Produkte mit den Preisen, alle Kategorien aus der alten Datenbank raus und zieht es in eine blanke Datenbank auf Basis der aktuellen Struktur (xtcommerce.sql) rein.
Ob die Daten aus dem Trunk kommen, der Version 1.0 / 1.1 / 1.3 ist völlig egal.

Alles was Ihr künftig machen müsst ist im Upgrader die aktuelle xtcommerce.sql zu hinterlegen. updater.sql Dateien wären NICHT mehr nötig, da es egal ist, was man vorher hatte, solange es ein xtCommerce Derivat war, bei welchem die Basisstruktur nicht verändert wurde.
Die Struktur entspricht ja dann immer der aktuellsten xtcommerce.sql - welche um die Stamm- und Bewegungsdaten ergänzt wurde.

Ihr benennt ja nie altes um, sondern erweitert es, deshalb muss das möglich sein.
Beispiel. In Version 1.03 wird aus product_description ja nicht produkt_beschreibung.