... | ... | @@ -3,26 +3,19 @@ Versionierung in QUIQQER |
|
|
|
|
|
Dieses Dokument beschreibt wie in QUIQQER Versionen festgelegt werden. Es soll für Plugin und Modul Maintainer ein kleiner Leitfaden sein und soll Ungereimtheiten beseitigen.
|
|
|
|
|
|
Grundlegendes
|
|
|
------
|
|
|
|
|
|
* QUIQQER hält sich an die [SemVer Notation](https://semver.org/)
|
|
|
Es gelten die folgenden Grundlagen:
|
|
|
* QUIQQER hält sich an die [SemVer Notation](https://semver.org/). Es wird vorausgesetzt, dass die Grundlagen bekannt sind.
|
|
|
* Für die Entwicklung und Versionierung wird [git](https://git-scm.com/) als Versionsverwaltung genutzt
|
|
|
* Alle QUIQQER Module sind unter https://dev.quiqqer.com/ zu finden
|
|
|
* Die QUIQQER Module werden zusätzlich nach https://github.com/quiqqer gespiegelt
|
|
|
|
|
|
Versionierung
|
|
|
------
|
|
|
|
|
|
Um die Versionierung von QUIQQER zu verstehen, setzen wir Kenntnisse der [SemVer Notation](https://semver.org/) voraus.
|
|
|
|
|
|
### Für Redakteure und Nicht-Entwickler
|
|
|
## 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 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.
|
... | ... | @@ -30,7 +23,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
|
... | ... | @@ -38,19 +31,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`.
|
|
|
|
... | ... | @@ -70,7 +63,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.
|
|
|
|
... | ... | @@ -87,7 +80,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.
|
|
|
|
... | ... | @@ -100,7 +93,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.
|
|
|
|
... | ... | |