# 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.