Diskussion zu phpBB 3.0 RC8 erschienen
- nickvergessen
- Ehrenadmin
- Beiträge: 11559
- Registriert: 09.10.2006 21:56
- Wohnort: Stuttgart, Germany
- Kontaktdaten:
Der Auto-Updateter findet die neuen Codestellen und die Stellen der bereits eingebauten MODs.
Er verschmelzt beide Codes ( merge ) solange die neue Codestelle und der MOD nicht die gleiche Zeile verändert haben. ( critical hit )
Nur wenn es eine kritische Stelle gibt, muss der User entscheiden welcher Code benutzt werden soll: Der von der neuen RC Version, oder der vom MOD.
Der Autoupdater von RC8 hat alle meine eingebauten MODs mit berücksichtigt. Ich habe beim Update kein einziges MOD "verloren".
Er verschmelzt beide Codes ( merge ) solange die neue Codestelle und der MOD nicht die gleiche Zeile verändert haben. ( critical hit )
Nur wenn es eine kritische Stelle gibt, muss der User entscheiden welcher Code benutzt werden soll: Der von der neuen RC Version, oder der vom MOD.
Der Autoupdater von RC8 hat alle meine eingebauten MODs mit berücksichtigt. Ich habe beim Update kein einziges MOD "verloren".
Ich will ja gar nicht den AutoUpdater abschaffen, aber zusätzlich die Codechanges fände ich sehr gut.
Ich hatte zwar bisher mit den Mods bei mir Glück gehabt, aber beim phpBB2 hatte ich mehrfach die Situation gehabt, daß ich bei Updates eine Stelle ändern musste die nicht nach dem Schema "alter oder neuer Code?" ablief. (Zum Beispiel wenn bei einer Datenbank-Abfrage neue Felder in einer Abfrage dazugekommen waren und diese Abfrage nun geändert wurde)
Ich finde den Updater auch bei den Styles sehr schlecht durchdacht, da er es nicht unterstützt wenn man die Styles in der Datenbank ändert. Die eigenen Styles sind auch problematisch, vor allem wenn sie sich sehr von prosilver und subsilver2 unterscheiden.
Gerade hier wären die Codechanges notwendig damit man sich trauen kann die Styles kreativer zu benutzen.
Ich hatte zwar bisher mit den Mods bei mir Glück gehabt, aber beim phpBB2 hatte ich mehrfach die Situation gehabt, daß ich bei Updates eine Stelle ändern musste die nicht nach dem Schema "alter oder neuer Code?" ablief. (Zum Beispiel wenn bei einer Datenbank-Abfrage neue Felder in einer Abfrage dazugekommen waren und diese Abfrage nun geändert wurde)
Ich finde den Updater auch bei den Styles sehr schlecht durchdacht, da er es nicht unterstützt wenn man die Styles in der Datenbank ändert. Die eigenen Styles sind auch problematisch, vor allem wenn sie sich sehr von prosilver und subsilver2 unterscheiden.
Gerade hier wären die Codechanges notwendig damit man sich trauen kann die Styles kreativer zu benutzen.
Ich verwende auch einen eigen Style, der auf Prosilver basiert.
Dadurch habe ich durch den automatischen Upload nix verloren, da der ja den eigenen Style nicht berücksichtigt.
Nun habe ich Prosilver (Original) mit meinen Style verglichen bzw. ich habe geschaut wo sich was am Datum der Dateiordner geändert hat.
Da wo Änderungen angezeigt wurden habe ich erstmal geschaut, ob ich diese Dateien überhaupt verändert habe. Wenn nicht, dann habe ich aktuallisiert.
Bei mir waren es eigentlich nur zwei bei denen ich manuelle Codechanges machen mußte. colour.css und content.css.
Dabei haben mir nickvergessen und dr.death geholfen in dem sie sich ganz viel Arbeit gemacht haben bzw. mir z.B. diesen link gezeigt haben:
https://nickvergessen.svn.sourceforge.n ... 1=22&r2=23
und ruckzuck war mein eigener Style wieder aktuell.
Also ich bin kein Crack, aber wenn es mehr nicht ist, kann ich damit leben.
Dankward
Dadurch habe ich durch den automatischen Upload nix verloren, da der ja den eigenen Style nicht berücksichtigt.
Nun habe ich Prosilver (Original) mit meinen Style verglichen bzw. ich habe geschaut wo sich was am Datum der Dateiordner geändert hat.
Da wo Änderungen angezeigt wurden habe ich erstmal geschaut, ob ich diese Dateien überhaupt verändert habe. Wenn nicht, dann habe ich aktuallisiert.
Bei mir waren es eigentlich nur zwei bei denen ich manuelle Codechanges machen mußte. colour.css und content.css.
Dabei haben mir nickvergessen und dr.death geholfen in dem sie sich ganz viel Arbeit gemacht haben bzw. mir z.B. diesen link gezeigt haben:
https://nickvergessen.svn.sourceforge.n ... 1=22&r2=23
und ruckzuck war mein eigener Style wieder aktuell.
Also ich bin kein Crack, aber wenn es mehr nicht ist, kann ich damit leben.
Dankward
Den User entscheiden lassen ob der Autoupdater nutzen will oder nicht. Auch werde ich das dumpfe Gefühl nicht los man holt in der RC Phase alles nach was in der Beta versäumt worden ist. Es gab nur 5 Betas und schon 8 RCs Und die RC Phase ist schon fast doppelt so lang wie die Betaphase.nickvergessen hat geschrieben:Das ist das Problem, wenn User MODs einbauen die in der Entwicklung stecken. Einige MODs sind auch definitiv noch nicht soweit.
Bei eigenen Styles ist das ganze natürlich noch was anderes. Aber wie sollen die den in den Autoupdater eingebaut werden? Das ist unmöglich.
Debian Lenny 5.0r0 * Kernel 2.6.28-1-amd64 * KDE 3.5.10 * Platte 1500 GB SATA-II
AMD Athlon(tm) Dual Core Processor 4850e * MSI K9N2 Diamond * 8192 MB DDR2-1066
AMD Athlon(tm) Dual Core Processor 4850e * MSI K9N2 Diamond * 8192 MB DDR2-1066
Du bist mir doch nicht böse, wenn ich sage, dass ich dem nicht wirkliche traue, oder?Dr.Death hat geschrieben:Der Auto-Updateter findet die neuen Codestellen und die Stellen der bereits eingebauten MODs.
Er verschmelzt beide Codes ( merge ) solange die neue Codestelle und der MOD nicht die gleiche Zeile verändert haben. ( critical hit )
Nur wenn es eine kritische Stelle gibt, muss der User entscheiden welcher Code benutzt werden soll: Der von der neuen RC Version, oder der vom MOD.
Der Autoupdater von RC8 hat alle meine eingebauten MODs mit berücksichtigt. Ich habe beim Update kein einziges MOD "verloren".

Wobei ich zugeben muss, dass das prinzipiell cool ist.