Versionierung

cwsoft · 04.08.2015 21:57:56

norhei schrieb:

Changes müssen/sollten enthalten wer ,was und wann.

Muss wirklich ne CHANGELOG mit? Auf GitHub kann jede Änderung nachvollzogen werden. Mann könnte in der README.md darauf hinweisen, dass auf GitHub alle Änderungen seit dem ersten Commit (WB 2.8.3 SP3) nachvollzogen werden können.

norhei schrieb:

Das "or any Later" ist wichtig damit wir Bibliotheken mit GPLv3 oder vielleicht einmal v4 einbinden können.

Guter Punkt. Gerade nochmal in Ryans WB 2.5.2 geschaut. Siehe da, in den Originalheadern steht GNU GPL 2 or any later. Sollte also kein Problem sein.

norhei schrieb:

Die Lizenzdatei muss vorhanden sein und halt auch den Garantieausschluss und das andere Gezumpel enthalten

Die Lizenzdatei LICENSE.md (inkl. Gezumpel) wird im WBCE Packet mit ausgeliefert. Die README.md geht darauf ein, dass von WebsiteBaker 2.3.8 SP4 geforkt wurde.

norhei schrieb:

Wenn Allerdings noch andere Copyrights drinstehen, müssen die Drinbleiben!! Das ist integraler Bestandteil der GPL.

Ja, aber daran hat sich bei WB in der Vergangenheit kaum einer geschert. Siehe z.B. Dateiheader in 2.8.0 und 2.8.3 (Änderungen von DarkViper).

Denke also es ist ok, das Copyright auf Ryan und WebsiteBaker Org. e.V. zu lassen.

Beitrag geändert von cwsoft (05.08.2015 00:41:28)

cwsoft · 05.08.2015 01:24:45

Habe Norheis Vorschläge aufgegriffen und die README und die Dateiheader nochmal upgedated.

Kommentare, weitere Anmerkungen? Für meinen Teil passt das so ganz gut.

norhei · 05.08.2015 08:19:49

Ja Changelog muss eigentlich mit , ist part der GPL. Wenn Wir die Automatisiert aus den Github Einträgen bauen können umso besser , da einfach vor jedem Release einmal machen und dazupacken und für die aktuellsten Änderungen einfach auf Git verweisen.

Es bei Ryan und Websitebaker .org zu lassen ist schlicht ein Lizenzverstoss . Es Spicht aber garnichts dagegen einfach Den Header zu lassen Wie er ist , und Nur wenn eine Datei geändert wird einen neuen Zu setzen. Das ist sogar ein toller Indikator, das wir an der Datei schon dran waren. Ist noch der Alte, wissen Wir sofort die Datei ist ne Altlast.

Persönlich fand ich es bei einigen WB Forks immer unerträglich das erst mal in alle Dateien der Projektheader reingeklebt wurde, es ist ein Open Source Projekt und es ist keine Schande , wenn man es nicht selbst gemacht hat den alten Header drin zu lassen . IRgendwie macht das den Eindruck als wenn man da sein EGO befriedigen müsste . Damit fällt auch das Problem mit den Copyrights weg , weil von Hand ist das kein Problem.

Wenn dann eine Datei Fast ganz ausgetauscht ist(Stichwort Schöpfungshöhe in DE), kann man auch die anderen Copyrights einfach weglassen. Sollte man sich aber von Fall zu Fall überlegen.

Einfach überall automatisiert einen Heade drüber klatschen halte ich für eine Schlechte idee (Weswegen Werner das vermutlich auch gemacht hat: "EGO, ALLES MEINS!").

florian · 05.08.2015 10:10:05

Ich hatte beim Testen gerade das Problem, dass sich mit dem aktuellen WBCE-Commit bestimmte Module nicht installieren lassen oder merkwürdig verhalten.

Bakery, OneForAll: Installation wird abgelehnt aufgrund der Zeile

[== PHP ==]
$PRECHECK['WB_VERSION'] = array('VERSION' => '2.7', 'OPERATOR' => '>=');

in der precheck.php

mpform: wirft im Backend ein Warning beim Versuch ein neues Feld anzulegen

 Warning: Cannot modify header information - headers already sent by (output started at /var/www/.../include/phplib/template.inc:668) in /var/www/../modules/mpform/modify_field.php on line 47

Die Zeile 47 gehört zu dieser if-Abfrage:

[== PHP ==]
if (WB_VERSION >= "2.8.2") {
        $field_id = $admin->checkIDKEY('field_id', false, 'GET');
        if (!$field_id) {
                $admin->print_error($MESSAGE['GENERIC_SECURITY_ACCESS'], ADMIN_URL);
                exit();
        }
} else {
        if(!isset($_GET['field_id']) OR !is_numeric($_GET['field_id'])) {
                header("Location: ".ADMIN_URL."/pages/index.php");
                exit(0);
        } else {
                $field_id = $_GET['field_id'];
        }
}

Es ist also nicht gut, die WB_VERSION auf 1.0.0 zu setzen.
Vielleicht sollte diese zwecks Kompatibilität auf irgend einen irrwitzigen Wert (99.99.99) gesetzt und tatsächlich eine neue Konstante WBCE_VERSION eingeführt werden?

norhei · 05.08.2015 10:45:15

Oder einfach auf 2.9.0 , weil das vermutlich nach dem Versionschema das sein wird was beim ersten Release rauskommt.

webbird · 05.08.2015 11:49:59

Ich reparier' das, ich hab ja Erfahrung damit. cool

https://github.com/WBCE/WebsiteBaker_Co … /issues/20

webbird · 05.08.2015 12:01:11

Probier mal die hier, die unterstützt dann auch LEPTON (ab Version 1.2).

florian · 05.08.2015 16:06:42

Installation von Modulen geht jetzt, löst aber nicht das Problem bei Versionsprüfungen in Modulen selbst - mpform zeigt immer noch o.g. Verhalten.

webbird · 05.08.2015 16:10:41

Das kann man nur lösen, indem man die Konstante WB_VERSION beläßt. Kann man z.B. in der config.php setzen.

define('WB_VERSION','2.8.3');

Bei BC haben wir eine Datei wb2compat.php für sowas. Die kann man irgendwann einfach wegschmeißen, wenn man sich von der Abwärtskompatibilität trennen will. big_smile

cwsoft · 05.08.2015 16:54:43

Für Bakery und oneForAll. Hier sollte es reichen in addon.precheck Module auf <= 2.8.4 zu testen.

Module die aber intern WB_VERSION abfragen und abhängig davon dies oder das tun, dürften die 1.0.0 aber nicht mögen.
Hier hilft aber 2.9.0 auch nur bedingt. Es könnte ja auch ein Modul geben das intern auf WB_VERSION == 2.8.3 prüft. Für den Fall hilft dann weder 1.0.0 noch 2.9.0. Dürfte aber nur sehr wenige dieser Module geben.

webbird · 05.08.2015 16:55:49

Wenn die die Konstante WB_VERSION verwenden und wir intern WBCE_VERSION dürfte es keine Probleme geben.

florian · 05.08.2015 17:00:55

Bitte eine möglichst globale Lösung. Es sollte tunlichst vermieden werden, dass sich WB-Module nicht auf Anhieb installieren lassen und/oder verschiedene Insellösungen geschaffen werden, die dann später für Verwirrung sorgen.
Insofern ist es mMn am besten, WB_VERSION bei 2.8.3 zu lassen und eine neue WBCE_VERSION-Konstante einzuführen.

cwsoft · 05.08.2015 19:44:03

webbird schrieb:

Wenn die die Konstante WB_VERSION verwenden und wir intern WBCE_VERSION dürfte es keine Probleme geben.

Yepp, denke auch dass das die sauberste Lösung wäre. WB_VERSION belassen und eine WBCE_VERSION einführen.

cwsoft · 05.08.2015 21:58:54

norhei schrieb:

Changes müssen/sollten enthalten wer ,was und wann. Also sozusagen die Commit Liste als printout
https://github.com/WBCE/WebsiteBaker_Co … its/master

Eventuell eine Alternative (z.B. als Link in der README.md oder LICENSE.md integriert:
https://github.com/WBCE/WebsiteBaker_CommunityEdition/compare/fc40d4ecd...master

Vielleicht gibts ja ein Script/API um das ganze als Textdatei oder HTML runterzuladen.

Beitrag geändert von cwsoft (05.08.2015 22:01:31)

cwsoft · 06.08.2015 00:40:24

norhei schrieb:

Changes müssen/sollten enthalten wer ,was und wann.
also sozusagen die Commit Liste als printout

Hab ein kleines Bash script erstellt, welches automatisch eine CHANGELOG.md aus den Commits der master branch eines lokalen WBCE Git Repos erstellt.

Die CHANGELOG.md hängt den Commits auf GitHub prinzipbedingt immer um eins hinterher.

norhei · 06.08.2015 23:17:09

Super , sollte reichen .

cwsoft · 09.08.2015 14:06:18

@all: Habe nochmal die Versionierung überarbeitet. Für WBCE werden nun die Konstanten WBCE_VERSION und WBCE_TAG gesetzt. Die Konstanten VERSION, REVISION, SP bleibem für WB-Classic und werden auf die geforkte Version gesetzt. Sollte jetzt keine gröberen Probleme mehr mit WB-Modulen geben.

Habe auch mal das upgrade script grob überarbeitet. Bitte mal testen und evtl. Fehler melden.

WBCE CMS Forum

#26 04.08.2015 21:57:56

Re: Versionierung

#27 05.08.2015 01:24:45

Re: Versionierung

#28 05.08.2015 08:19:49

Re: Versionierung

#29 05.08.2015 10:10:05

Re: Versionierung

#30 05.08.2015 10:45:15

Re: Versionierung

#31 05.08.2015 11:49:59

Re: Versionierung

#32 05.08.2015 12:01:11

Re: Versionierung

#33 05.08.2015 16:06:42

Re: Versionierung

#34 05.08.2015 16:10:41

Re: Versionierung

#35 05.08.2015 16:54:43

Re: Versionierung

#36 05.08.2015 16:55:49

Re: Versionierung

#37 05.08.2015 17:00:55

Re: Versionierung

#38 05.08.2015 19:44:03

Re: Versionierung

#39 05.08.2015 21:58:54

Re: Versionierung

#40 06.08.2015 00:40:24

Re: Versionierung

#41 06.08.2015 23:17:09

Re: Versionierung

#42 09.08.2015 14:06:18

Re: Versionierung

Fußzeile des Forums