WebsiteBaker Support (2.8.x) > Diskussion über WB (closed)

Tests & Probleme der SVN Revision 1374 - 2.8.2 RC

<< < (48/62) > >>

Luisehahne:

--- Quote ---daß evtl. aus Sicherheitsgründen Code2 nicht mehr nutzbar sein könnte
--- End quote ---

warum sollte es nicht? Wir wollen doch kein Modul aussperren. Für die Sicherheit ist jeder Moduleauthor selber verantwortlich.

Dietmar

HANS 0:
Naja, wenn sowas kommt

--- Quote ---ist geplant das code-modul gegen code2 auszutauschen?
Nein. Es geht eher in die andere Richtung, also das Code Modul generell rauszunehmen und / oder irgendwann etwas anderes zu nehmen.
--- End quote ---
weiß ich doch nicht mehr wo's hingeht. Da ist doch Alarm angesagt, zumindest wenn nach einem Upgrade Probleme zu befürchten sind. Da lasse ich doch dann die Finger von. Wäre ja Sabotage.

Waldschwein:

--- Quote from: Hans Toolbox on July 29, 2010, 02:17:04 AM ---Naja, wenn sowas kommt

--- Quote ---ist geplant das code-modul gegen code2 auszutauschen?
Nein. Es geht eher in die andere Richtung, also das Code Modul generell rauszunehmen und / oder irgendwann etwas anderes zu nehmen.
--- End quote ---
weiß ich doch nicht mehr wo's hingeht. Da ist doch Alarm angesagt, zumindest wenn nach einem Upgrade Probleme zu befürchten sind. Da lasse ich doch dann die Finger von. Wäre ja Sabotage.

--- End quote ---

Ja meine Güte - es geht um das Code (!) Modul das im WebsiteBaker Paket (!) in allen Versionen seit 2.2.0 (Dezember 2004) dabei ist. Was hat das Code Module mit dem Code2 Module denn zu tun? Rein gar nichts.
Es geht nur darum, dass definitiv und eindeutig gesagt wurde in einer Vorstandssitzung o ich Protokoll geführt habe, dass Code2 niemals im Paket per Standard Einzug halten wird und wenn überhaupt Code entweder rausfliegt oder halt angepasst wird.
Dass du nach einem Upgrade Probleme befürchten musst ist unausweichlich. Die Chance ist momentan extrem gering, aber auf absolut 0 zu setzen ist unmöglich - egal bei welchem CMS, egal bei welchem Betriebssystem.
Und ich lege meine Hand ins Feuer, dass die 100% gleiche Code2-Version von heute (29. Juli 2010) im nächsten Majorrelease ( WB 3) nicht ohne Anpassung des Moduls funktionieren wird. Weil alles andere ist entweder nicht möglich oder rechtfertigt keine neue Versionsnummer.
Aber es tut doch keinem Weh - ein Upgrade kann man immer laufen lassen. Wenn man davor Angst hat sollte man sich generell von Computern verabschieden und wieder mit Zettel & Block arbeiten.

Gruß Michael

dbs:

--- Quote ---Aber es tut doch keinem Weh - ein Upgrade kann man immer laufen lassen
--- End quote ---

wenn eine wb-installation danach nicht mehr funktioniert wie vorher?
da kann man sich wohl berechtigte sorgen machen. was soll der normal-user dann tun? downgrade?

Waldschwein:

--- Quote from: dbs on July 29, 2010, 09:34:58 AM ---
--- Quote ---Aber es tut doch keinem Weh - ein Upgrade kann man immer laufen lassen
--- End quote ---

wenn eine wb-installation danach nicht mehr funktioniert wie vorher?
da kann man sich wohl berechtigte sorgen machen. was soll der normal-user dann tun? downgrade?

--- End quote ---

Darum testen wir ja. Dass etwas evtl. anders funktioniert (aber funktional gleich bleibt) sollte selbstverständlich sein.
Ich gehe immer vom Normal-Benutzer auf, der keine Anleitung durchliest (es ist völlig egal was sich der Entwickler denkt egal bei was, nicht bloß im PC-Bereich, Anleitungen werden grundsätzlich erst dann gelesen, wenn etwas nicht funktioniert), sondern nur das macht, was er laut dem System tun muss.
Was genau macht eigentlich ein Upgrade?
In der Datenbank stehen die ganzen Werte, die der Admin / Editor / usw. von vorher eingetippt hat. Die Datenbank ist das Herzstück. Egal wie frontend.css usw. aussieht - alles was PHP, HTML, CSS betrifft kann bei einem Upgrade hinüber sein, manchmal ist es sogar gut so, häufig lässt es sich gar nicht vermeiden. Meistens regt sich abe keiner auf, weil die Änderungen schnell wieder gemacht werden, wenn überhaupt gebraucht.

Das eigentlich wichtige bei einem Upgrade ist es, die Informationen, die in der Datenbank stehen so auszulesen / zu verändern, dass sie auch mit dem technisch neuen System zusammenarbeiten.
Wer z.B. ein Forum einmal von einer Software auf eine andere umgezogen hat wundert sich, dass sehr vieles (häufig sogar Systemeigene Einstellungen) meistens ohne Probleme übernommen wird, obwohl die Software von der upgegradet wurde in keinster Weise auch nur im Ansatz der anderen ähnelt.
Genau hier kann upgrade anfangen. Ich sehe hier auch keine Probleme - wird ein Upgrade richtig gemacht, gibt es sogar ein "FallBack", dass eben die alten Daten gar nicht angerührt werden, und man so gar keinen Downgrade braucht, sondern einfach vorerst das alte weiter behält.
Wer aber ein einfaches Datenbank-Backup gemacht hat, braucht sich keinerlei Gedanken machen.
Upgradeprobleme im größeren Stil gab es eigentlich nur von WB 2.5.x auf WB 2.6.x, schlichtweg deshalb, weil es damals 20 verschiedene Upgradedateien gab von denen keine so richtig funktioniert hat.
Heutzutage funktioniert es im Regelfall schon, deswegen müssen wir das austesten.
Und noch einmal: WebsiteBaker 3 wird niemals ohne Anpassungen der Module von WebsiteBaker > 2.6 möglich sein, es geht gar nicht technisch (außer eine automatische Anpassung). Aber s.o. - darüber muss man sich doch keine Gedanken machen. Wenn es soweit ist kann das ja jeder selbst nachvollziehen. Und das ist eh alles hypothetisch - das "große" Drupal hat in der Zeit wo WB keinen Bruch hatte bis heute 3-4 Major-Releases hinter sich, wo jedes Mal tausende, technisch unterschiedliche Module (vielfältig kommerzielle) angepasst werden musste. Beschwert hat sich aber kaum jemand. Daher verstehe ich nicht so ganz die Angst davor. Irgendwann ist halt Schluss - Windows 98 Programme laufen ja auch nicht auf Windows XP, und die nur selten auf Windows 7 64bit, selbiges übrigens bei Linux und angebissenen Apfel. Und das ist wirklich eine andere Dimension als bei WB.

Gruß Michael

Navigation

[0] Message Index

[#] Next page

[*] Previous page