85 lines
3.6 KiB
Markdown
85 lines
3.6 KiB
Markdown
|
# Schritte beim Release einer neuen Version
|
||
|
|
Dieses Dokument beschreibt das Vorgehen beim Erstellen einer neuen Version von OMDS 3.
|
||
|
|
|
||
|
|
## Vorgehen im Git
|
||
|
|
|
||
|
|
Es wird das Vorgehensmodell *Git-Flow* verwendet.
|
||
|
|
|
||
|
|
Wir gehen vom Development-Branch aus und machen einen Release-Branch im Git. Dort werden die Änderungen vorgenommen,
|
||
|
|
die vor der Veröffentlichung passieren müssen. Er steht dann als Release-Candidate zur Begutachtung zur Verfügung.
|
||
|
|
|
||
|
|
Der Release-Branch wird nach Abschluss der unten beschriebenen Schritte und nach Erstellung des Zips für die
|
||
|
|
Veröffentlichung in den Master Branch gemerged.
|
||
|
|
|
||
|
|
Unter Umständen werden einige Änderungen am Release Candidate bzw. dann am Master auch in den Development-Branch
|
||
|
|
rückübernommen. Damit man den Master-Branch dann wieder problemlos nach Development mergen kann und somit Development
|
||
|
|
auch auf dem exakten Stand der Veröffentlichung ist, ist es sinnvoll im Development vor dem Merge den Folder für die
|
||
|
|
neue Version anzulegen und diesen Folder mit den noch unveränderten XSDs zu befüllen.
|
||
|
|
|
||
|
|
|
||
|
|
## Bearbeitung der Norm im Development-Branch
|
||
|
|
|
||
|
|
### OMDS 2
|
||
|
|
Prüfen ob die richtige OMDS 2 XSD enthalten ist.
|
||
|
|
|
||
|
|
### OMDS 3
|
||
|
|
Abgrenzung des Veröffentlichungsumfangs - nicht alles aus dem Development-Branch wird veröffentlicht.
|
||
|
|
|
||
|
|
Insbesondere ist hier um etwaige Fehler auszuschließen nochmals gegen die tatsächlich veröffentlichten XSDs der
|
||
|
|
letzten Veröffentlichung zu prüfen.
|
||
|
|
|
||
|
|
Anpassung der Versions-Tags im in den XSDs und den Kommentar im WSDL.
|
||
|
|
|
||
|
|
|
||
|
|
### Überarbeitung der Dokumentation
|
||
|
|
Dokumente haben einen Kopf bestehend aus:
|
||
|
|
* Titel
|
||
|
|
* Status: Empfehlung, vorgeschlagener oder freigegebener Standard
|
||
|
|
* Release: Versionsnummer des Releases
|
||
|
|
* Ansprechpartner
|
||
|
|
* Dokumentenhistorie
|
||
|
|
* Voraussetzungen
|
||
|
|
* Rechtliche Hinweise
|
||
|
|
* Inhaltsverzeichnis
|
||
|
|
|
||
|
|
Dokumente sollen im Kopf die Versionsnummer tragen, damit der Leser
|
||
|
|
gleich erkennen kann, zu welcher Version das Dokument gehört.
|
||
|
|
|
||
|
|
Der Status des Service (0-Entwurf, 1-Empfehlung, 2-Vorgeschlagener Standard, 3-Freigegebener Standard)
|
||
|
|
soll beim jeweiligen Service notiert sein und im Dokument ON_1.01.4_VerzeichnisOperationen.
|
||
|
|
|
||
|
|
In der Fußzeile findet sich ein Copyright Hinweis, der ggf. aktualisiert werden muss.
|
||
|
|
|
||
|
|
## Abspaltung des Release Candidate
|
||
|
|
Der Release-Candidate wird als "release/Versionsnummer" vom Development-Branch abgespalten.
|
||
|
|
Die Versionsnummer wird um "RC" ergänzt, behält aber den Zusatz "SNAPSHOT".
|
||
|
|
|
||
|
|
Im Release-Candidate werden die Inhalte entfernt, die im Development-Branch enthalten sind,
|
||
|
|
aber nicht in den Release eingehen sollen.
|
||
|
|
|
||
|
|
Im Development-Branch wird das Verzeichnis für die nächste Version angelegt und die XSDs in
|
||
|
|
dieses neue Verzeichnis übernommen. Es wird eine neue Versionsnummer mit Zusatz "SNAPSHOT" vergeben.
|
||
|
|
|
||
|
|
## Merge in den Master-Branch
|
||
|
|
### Versionsnummer im Pom
|
||
|
|
Die Versionsnummer im Pom ist zu setzen, ein etwaiges "SNAPSHOT" zu streichen.
|
||
|
|
|
||
|
|
Der Release-Candidate wird in den Master-Branch gemerged.
|
||
|
|
|
||
|
|
## Bau der Veröffentlichung
|
||
|
|
### Generierung der XSD Dokumentation mit XmlSpy
|
||
|
|
Mit Hilfe von XML-Spy die Dokumentation für jedes XSD in das Verzeichnis
|
||
|
|
OMDSServiceDefinition/docGen generieren (wird nicht ins Git geladen).
|
||
|
|
|
||
|
|
### JavaDoc Generierung
|
||
|
|
Es sind die Javadocs per Maven Target zu generieren (bei package inkludiert).
|
||
|
|
|
||
|
|
### Build
|
||
|
|
In der Datei assembly.xml ist vorgegeben, welche Verzeichnisse für die Veröffentlichung
|
||
|
|
zusammengepackt werden. In assembly.xml muss die Versionsnummmer des Release angepasst werden.
|
||
|
|
Mit Maven "install" kann der Release gebaut werden.
|
||
|
|
|
||
|
|
## Rückmerge in den Development-Branch
|
||
|
|
Die Definitionen der Veröffentlichung und die zugehörigen Klassen werden in den Development-Branch
|
||
|
|
zurück gemerged.
|