Versionierung

webbird · 30.07.2015 11:04:30

Es wurden ja schon Releasezyklen vorgeschlagen, was vielleicht ein bißchen weit gesprungen ist. Zunächst sollte man sich mal Gedanken über die Versionierung machen.

Ich hatte die Beta ja erst mal "WBCE1" genannt, unter der Annahme, daß es sich "nur" um ein WB mit ein paar Patches und aktualisierten Modulen handelt, die man dann weiter ausbaut, wenn es notwendig ist. Durch die Beteiligung einiger Ex-Entwickler von WB kann es jetzt etwas Größeres werden, mit sozusagen "echten" Neu- und Weiterentwicklungen. Daher sollte man sich wirklich Gedanken darüber machen, wie man das Ding nennen will. Dabei geht es mir nicht um die unsäglichen SPs, sondern sozusagen um die Grundversion. Was ist die erste WBCE für eine Version? 2.8.3? 2.8.4? 2.9? Oder 1.0?

Noch kurz zur "klassischen" Versionierung, die den meisten vertraut sein dürfte, halt mit Ausnahme der verantwortlichen WBler. *hüstel*

1. Stelle - Major version (Hauptversion)
Größere _sichtbare_ Änderungen.

2. Stelle - Minor version (Unterversion)
Kleinere Änderungen, wobei das in Relation zu den wirklich großen zu sehen ist. Kleiner heißt nicht klein.

3. Stelle - Patch (Bugfixes)
Beinhaltet ausschließlich Fehlerkorrekturen, keine funktionalen Änderungen.

Eigentlich müßte WB 2.8.3 demnach mindestens 2.8.7 heißen, 2.8.4 ist entweder eine 2.9 oder gar eine 3.0.

Ich würde empfehlen, das konsequent durchzuziehen. Auch wenn's einen oft in den Fingern juckt, eine Verbesserung schon in ein Bugfix Release zu packen. big_smile Dann lieber vor der Zeit ein neues Minor release, auch wenn das dann vielleicht nur diese eine Verbesserung beinhaltet. Wenn's halt eine wichtige ist...

Zur Unterscheidung Major-Minor: Teilweise schwierig, auch Minor-Versionen können große Sprünge machen. Für ich ist z.B. die vollständige Überarbeitung des Rechtesystem eine klare Hauptversion. Die neue Datenbank Engine haben wir in einem Minor Release untergebracht, weil das für den Benutzer nicht sichtbar ist und ohne Kompatibilitätsbrüche möglich war.

Edit: Sorry, beim Speichern war das Ding abgekackt, zum Glück konnte ich den Text noch schnell kopieren.

easyuser · 30.07.2015 19:31:45

webbird schrieb:

Noch kurz zur "klassischen" Versionierung, die den meisten vertraut sein dürfte, halt mit Ausnahme der verantwortlichen WBler. *hüstel*

Also in der "Hoch-Zeit von WB" war die klassische Versionierung noch üblich.

Ich hoffe doch sehr, dass bei WBCE keine SPs und Hotfixes gibt - da kennt sich niemand mehr nur noch ansatzweise aus. Ganz zu schweigen davon, dass man diese 5-Stufige Versionierung bei WB auch programmiertechnisch gar nicht mehr abbilden kann.

Ich plädiere auch für die 3-Stufige Versionierung, wobei ja die 2- (z.B. Drupal) oder 1- stufig (Chrome, Firefox) auch nicht zu verachten ist.

Ich würde ehrlich gesagt den ersten Release von WBCE entweder 1.0 oder 3.0 nennen - aber das ist eher eine politische als eine technische Frage.

Und: Nach der .9 kommt... Richtig, nicht die 1.0, sondern die .10. Zumindest wenn ich in Mathe richtig aufgepasst habe. wink

cwsoft · 30.07.2015 19:51:04

Ich vote auch für eine Semantische Versionierung.

webbird · 31.07.2015 12:22:25

Der Inhalt eines Pakets mit einer Versionsnummer DARF NICHT mehr verändert werden, wenn es einmal veröffentlicht ist. Jegliche Änderungen MÜSSEN als neue Version herausgegeben werden.

*hust*

easyuser · 31.07.2015 14:53:21

webbird schrieb:

Der Inhalt eines Pakets mit einer Versionsnummer DARF NICHT mehr verändert werden, wenn es einmal veröffentlicht ist. Jegliche Änderungen MÜSSEN als neue Version herausgegeben werden.
*hust*

Naja, das war eigentlich auch mal so: http://forum.websitebaker.org/index.php?topic=6674.0 cool

webbird · 31.07.2015 16:11:27

Ja, es war einiges mal so wie es sein sollte... Damals... *seufz* Das waren noch Zeiten...

norhei · 31.07.2015 16:16:31

Semantische Versionierung

Bringt es glaube ich gut auf den Punkt ! Wäre ich für zu haben! Fühlt sich gut an !

Demnach wäre das was wir grade machen einen 2.9.0, da wir ja unbedingt Kompatibel bleiben wollen?
Man könnte es auch in mehrere Schritten hochzählen, ala 2.18.0 , aber ob das dem alten WB Nutzer dann noch vertraut ist ???

Wenn wir das Dingen soweit zusammen hätten das wir denken mach mal einen Release würde die Nummer also auf 2.9.0-Alpha gesetzt , die vermutlich erforderlichen Patches wären dann 2.9.1|2|3.....

Eigentlich auch ein guter Grund Single Tab einfach noch drin zu lassen, zumal es ja sowieso nicht mehr Standard ist....
Ich finde so ein Schema hilft beim beurteilen der Änderungen und Versionen. Gute Idee.

Eigentlich habe ich das bei meinen eigenen Projekten eigentlich eh schon so gemacht, aber es ist prima aufgeschreiben!
Maximale Verlässlichkeit für den Anwender und den Modul Author und einfach anzuwenden! Das legt es schön und für Jeden nachvollziehbar fest .

Gefällt mir!

SP1...SP2...usw., Riesenänderungen in minor Releases , die ganze jetzige Versionierung ... das ist irgendwie ... unprofessionell

florian · 31.07.2015 16:28:03

Die Versionsnummer von WB classic ist doch schon lange nicht mehr aussagekräftig.
Kompatibilität ja, Anbiederung nein. WBCE wird trotz Kompatibilität was ziemlich eigenes, das zeichnet sich hier bereits ab, und es könnte ja möglicherweise irgendwann doch noch von WB classic eine 2.8.4 oder gar 2.9 geben, dann wird es verwirrend, wenn bei WBCE ähnliche Versionsnummern verwendet werden.
Ich halte es für besser, bei 1 anzufangen, sprich das erste Release wäre WBCE 1.0.0.
Das Gegenteil einer semantischen Versionierung ist dann vermutlich das, was Firefox, Chrome & Co. vormachen, also einfach ganze Nummern hochzählen: WBCE 1, 2, 3...42 ?
(Habe den verlinkten Text nicht gelesen, tl;dr gerade ops )

webbird · 31.07.2015 16:55:00

Zum einen ist diese Art der Versionierung ja nicht verbindlich vorgeschrieben, insofern kann das jeder handhaben, wie er möchte. Zum anderen bringen Firefox & Co. in den Major Releases durchaus auch Neuerungen. Ab und zu gibt es auch mal Bugfix Releases, jedenfalls bei FF. So gesehen halten sie sich schon entfernt dran. Es ist halt, wie schon gesagt, auch manchmal schwer zu entscheiden, ob eine neue Funktion ein Major Release rechtfertigt oder nicht. In meiner Firma kommen grundlegende Änderungen auch in Minor Releases vor, was ich persönlich unschön finde, aber wie gesagt - es ist nicht festgeschrieben.

Wenn man es wirklich so handhaben will, daß nur Kompatibilitätsbrüche einen Major Release bedeuten, kommen manche nie über eine 1.x hinaus. big_smile Das ist ja auch doof.

norhei · 31.07.2015 19:44:33

@ florian

Mein Gedanke war das wegen der WB Module mit Versionsprüfung nahe am WB zu lassen. Nehmen wir 1.0 meckern die alle, das die WB Version zu alt ist. -> viel Arbeit alle zu überprüfen und das zu ändern. Das hatte ich bei meinem alten Fork schon mal, war extrem nervig auch wenn ein WB Wodul öffter ein Upgrade bekam. Dann musste ich immer wieder und wieder die Info abändern.

@webbird
Fänd ich jetzt nicht so schlecht.
Version 1.179.5 zeigt dann gleich das man bei dieser Software sehr selten mit Problemen der Abwärtskompatibilität zu kämpfen hat. Und wenn dann doch mal Major Sprünge drin sind kann man sehen wie häufig man mit sowas rechnen muss, denn das bedeutet immer extra Aufwand.

cwsoft · 31.07.2015 22:43:47

norhei schrieb:

Mein Gedanke war das wegen der WB Module mit Versionsprüfung nahe am WB zu lassen. Nehmen wir 1.0 meckern die alle, das die WB Version zu alt ist. -> viel Arbeit alle zu überprüfen und das zu ändern.

Bedarf eigentlich nur einer Anpassung der "framework/addon.precheck.inc.php". Dort den "WB_VERSION" Check anpassen (z.B. alles >= 2.8.3 ok alles darunter Fehler). Generell sollte man hier auch gleich eine WBCE_VERSION implementieren.

Ich persönlich fände es besser, mit einer WBCE 1.0.0 zu beginnen.

norhei · 01.08.2015 00:48:32

Können ja einfach ne kleine Abstimmung starten , gibts sowas als plugin fürs modul ?

wb_user82 · 01.08.2015 13:41:12

Die Frage ist ja auch, ob unter den Umständen WB Classic überhaupt noch weiterentwickelt werden kann, denn die wichtigsten Personen sind ja bereits aus dem Boot ausgestiegen und entweder hier oder bei BlackCat.

Wenn das hier erfolgreich wird, und wir nicht die gleichen Fehler machen wie drüben, dann wird das hier sehr wahrscheinlich die Weiterentwicklung von WB Classic werden...

webbird · 03.08.2015 11:15:07

BC hat ja das gleiche Problem mit den Versionsnummern, da wir auch bei 1.0 angefangen haben. Bei uns isses sogar noch schlimmer, weil wir auch noch LEPTON unterstützen. (Wobei es meines Wissens weniger Original-LEPTON-Module gibt als BC-Module.) Unsere Precheck-Prüfung sieht daher etwas wild aus, auf WBCE runtergebrochen ist es aber ganz einfach:

Wenn Konstante WB_VERSION gesetzt/gefragt, prüfe auf 2.8.3. Ansonsten prüfe Konstante WBCE_VERSION.

Somit hat man auch eine saubere Trennung zwischen WBCE-Originalmodulen und WB-vererbten Modulen.

webbird · 03.08.2015 11:15:56

Die Frage ist ja auch, ob unter den Umständen WB Classic überhaupt noch weiterentwickelt werden kann

DV hat schon seit Jahren niemanden mehr an die Core-Entwicklung dran gelassen, was kratzt es sie, ob Entwickler abwandern oder nicht...

norhei · 03.08.2015 11:16:58

DV hat aber auch seit Jahren nichts mehr auf die Kette bekommen big_smile

webbird · 03.08.2015 11:18:26

Daher stellt sich die Frage einer Weiterentwicklung auch nicht. big_smile

norhei · 03.08.2015 11:41:05

Rofl lol

cwsoft · 04.08.2015 01:32:00

Ok, habe mal eine erste Version für WBCE mit semantischer Versionierung auf GitHub gestellt. Die intiale VERSION habe ich auf 1.0.0 gesetzt (kann man vor dem Release ändern). Die Konstanten SP und REV habe ich aufs Altenteil geschickt und stattdessen die Konstante TAG eingeführt. TAG bezeichnet hier den WBCE Release-Tag auf GitHub. Somit kann man über ein Link im Backend den aktuellen Commit auf GitHub einsehen.

Wer sichs mal anschauen mag.

Beitrag geändert von cwsoft (04.08.2015 01:32:20)

norhei · 04.08.2015 09:10:33

WebsiteBaker Community Edition (WBCE)
More Baking. Less Struggling.
Visit http://wbce.org to learn more or to join the community.

@copyright Ryan Djurovich (2004-2009)
@copyright WebsiteBaker Org. e.V. (2009-2015)
@copyright WBCE Project(2015)
Licensed under GNU GPL2 or any later version see LICENSE.MD for details .

Die Lizenzdatei muss vorhanden sein und halt auch den Garantieausschluss und das andere Gezumpel enthalten siehe http://www.gnu.org/

Ich denke dann wäre es rund.
Wenn Allerdings noch andere Copyrights drinstehen, müssen die Drinbleiben!!
Das ist integraler Bestandteil der GPL.

Für das Ebenfalls notwendige ChangeLog würde ich einfach mal versuchen auf Github zu verweisen. (Oder kann man Über Github ein Changelog ausdrucken/synchronisieren?)

norhei · 04.08.2015 09:13:01

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

webbird · 04.08.2015 11:05:47

Was genau willst Du im Changelog drin haben? Ich habe ein lokales Script, das die Issues auflistet, die seit einem bestimmten Tag bearbeitet wurden. Du kannst auch eine Liste der geänderten Dateien erzeugen. Sowas geht, ja.

norhei · 04.08.2015 11:14:02

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

also sozusagen die Commit Liste als printout

https://github.com/WBCE/WebsiteBaker_CommunityEdition/commits/master

wenn es automatisiert geht , wär es vielleicht nicht schlecht , die kompletten texte zu nehmen, nicht nur die Headlines

Beitrag geändert von norhei (04.08.2015 11:15:24)

webbird · 04.08.2015 11:19:56

Probier mal git log.

webbird · 04.08.2015 11:21:50

Etwas vollständiger... wink

git log 1.1...HEAD --oneline

1.1 ist das Tag, wo begonnen werden soll, HEAD der aktuelle Stand. Ergebnis ist sowas wie

54ccbdd fix for global header files; some changes in Addons helper; getConfig()
bec3e28 removed scan_current_dir() from media/index.php; added module usage info
66911c8 some fixes in installer; fix in DB helper
55ad32b added DB subfolder in CAT/Helper
.....

Geht auf dem lokalen Clone, Verbindung zu Github ist nicht nötig.

WBCE CMS Forum

#1 30.07.2015 11:04:30

Versionierung

#2 30.07.2015 19:31:45

Re: Versionierung

#3 30.07.2015 19:51:04

Re: Versionierung

#4 31.07.2015 12:22:25

Re: Versionierung

#5 31.07.2015 14:53:21

Re: Versionierung

#6 31.07.2015 16:11:27

Re: Versionierung

#7 31.07.2015 16:16:31

Re: Versionierung

#8 31.07.2015 16:28:03

Re: Versionierung

#9 31.07.2015 16:55:00

Re: Versionierung

#10 31.07.2015 19:44:33

Re: Versionierung

#11 31.07.2015 22:43:47

Re: Versionierung

#12 01.08.2015 00:48:32

Re: Versionierung

#13 01.08.2015 13:41:12

Re: Versionierung

#14 03.08.2015 11:15:07

Re: Versionierung

#15 03.08.2015 11:15:56

Re: Versionierung

#16 03.08.2015 11:16:58

Re: Versionierung

#17 03.08.2015 11:18:26

Re: Versionierung

#18 03.08.2015 11:41:05

Re: Versionierung

#19 04.08.2015 01:32:00

Re: Versionierung

#20 04.08.2015 09:10:33

Re: Versionierung

#21 04.08.2015 09:13:01

Re: Versionierung

#22 04.08.2015 11:05:47

Re: Versionierung

#23 04.08.2015 11:14:02

Re: Versionierung

#24 04.08.2015 11:19:56

Re: Versionierung

#25 04.08.2015 11:21:50

Re: Versionierung

Fußzeile des Forums