... | ... | @@ -18,9 +18,11 @@ Um die Versionierung von QUIQQER zu verstehen, setzen wir Kenntnisse der [SemVer |
|
|
|
|
|
### Für Redakteure und Nicht-Entwickler
|
|
|
|
|
|
Ein QUIQQER Paket (Modul / Plugin) besteht immer aus verschiedenen Entwicklungszweigen (Branches). Ein Branch repräsentiert also einen bestimmten Entwicklungsstand des Paketes. So zum Beispiel eine bestimmte Version.
|
|
|
Ein QUIQQER Paket (Modul / Plugin) besteht immer aus verschiedenen Entwicklungszweigen (Branches). Ein Branch repräsentiert also einen bestimmten Entwicklungsstand des Paketes. So zum Beispiel eine bestimmte Version.
|
|
|
|
|
|
Ein Paket kann (unter anderem) die nachfolgenden Branches aufweisen:
|
|
|
|
|
|
### master (dev-master)
|
|
|
#### master (dev-master)
|
|
|
|
|
|
Der master Zweig beinhaltet folgendes:
|
|
|
- Im master Zweig sind Behebungen oder Features vorhanden welche schon fertig entwickelt sind.
|
... | ... | @@ -28,7 +30,7 @@ Der master Zweig beinhaltet folgendes: |
|
|
|
|
|
**Da unter Umständen nicht alle Features getestet sind, ist der master Zweig nur eingeschränkt für den Produktivbetrieb zu empfehlen.**
|
|
|
|
|
|
### dev (dev-dev)
|
|
|
#### dev (dev-dev)
|
|
|
|
|
|
Der dev Zweig beinhaltet immer die aktuellste - möglicherweise instabile - Version eines QUIQQER Paketes.
|
|
|
- In diesem Zweig wird direkt entwickelt
|
... | ... | @@ -36,20 +38,19 @@ Der dev Zweig beinhaltet immer die aktuellste - möglicherweise instabile - Vers |
|
|
|
|
|
**Diese Version ist nur für Entwickler vorgesehen und niemals für den Produktivbetrieb geeignet.**
|
|
|
|
|
|
### Versionen (1.0, 2.0)
|
|
|
#### Versionen (1.0, 2.0)
|
|
|
|
|
|
Jede Haupt-/Major-Version besitzt einen eigenen Branch. Je nach Größe des Projektes erhalten auch Minor-/Neben-Versionen ihren eigenen Branch.
|
|
|
|
|
|
**Diese Versionen sind getestet und wurden für stabil befunden. Damit sind sie für den Live Betrieb geeignet.**
|
|
|
|
|
|
Für Entwickler
|
|
|
------
|
|
|
### Für Entwickler
|
|
|
|
|
|
### Grundlegende Entwicklungs-Branches (für ein neues QUIQQER Paket)
|
|
|
#### Grundlegende Entwicklungs-Branches (für ein neues QUIQQER Paket)
|
|
|
|
|
|
Wenn du als Entwickler ein neues Paket anlegst, sollten die Branches `dev` und `master` direkt zu Anfang angelegt werden. Diese zwei Branches sind die Grundlage für dein neues Repository.
|
|
|
|
|
|
### Versions-Branches
|
|
|
#### Versions-Branches
|
|
|
|
|
|
Wenn dein `master`-Branch in einem stabilen Zustand und ausreichend getestet ist, kannst du daraus einen Versions-Branch abzweigen. Der Versions-Branches sollte wie folgt benannt werden: `<major version number>.<minor version number>`. Also zum Beispiel: `1.0`, `1.1`, `1.2`, `2.0`.
|
|
|
|
... | ... | @@ -69,7 +70,7 @@ git checkout -b 1.0 |
|
|
git push origin 1.0
|
|
|
```
|
|
|
|
|
|
### Vorgehen eines Releases (MAJOR, MINOR)
|
|
|
#### Vorgehen eines Releases (MAJOR, MINOR)
|
|
|
|
|
|
QUIQQER nutzt GitLab als Projektverwaltung. Releases sind in GitLab sehr einfach anzulegen, daher solltest du auch GitLab als Oberfläche nutzen.
|
|
|
|
... | ... | @@ -86,7 +87,7 @@ Wenn du diese Schritte gemacht hast, musst du nur noch ein Tag 1.0.0 anlegen um |
|
|
* Danach noch alle Felder ausfüllen und der Tag kann erstellt werden
|
|
|
Wenn du alles richtig gemacht hast, taucht das neue Release auf der Release Seite auf. Zum Beispiel: https://dev.quiqqer.com/quiqqer/package-smarty/-/releases
|
|
|
|
|
|
### Vorgehen eines Patches
|
|
|
#### Vorgehen eines Patches
|
|
|
|
|
|
Damit du ein Patch veröffentlichen kannst, ist ein nicht so kompliziertes Vorgehen nötig.
|
|
|
|
... | ... | @@ -99,7 +100,7 @@ D.h. im Branch 1.0 werden alle Patches gemacht welche 1.0.* betreffen. Für den |
|
|
|
|
|
*Wichtig: Wenn du neue Versionsbranches erstellst, denke immer daran die composer.json anzupassen. In den dev-dev und dev-master Branches ist in der composer.json **KEINE** Version anzugeben.*
|
|
|
|
|
|
### Kleinere Module
|
|
|
#### Kleinere Module
|
|
|
|
|
|
Bei kleineren Modulen kann der MINOR Schritt übergangen werden. Anstatt dann 1.0 und 1.1 Branches zu erstellen reicht es wenn ein 1 und 2 oder 3 Branch erstellt wird. Patches werden dann direkt in die MINOR Branches eingespielt.
|
|
|
|
... | ... | |