ReleaseNotes angepasst, Beschreibung des Release-Vorgehens verbessert,

Codegenerierung umgestellt: mit jedem Package wird der Code generiert, aber nicht mehr vom WSDL, sondern nur von den XSDs.

OMDSServiceDefinition/HowToRelease.md

@@ -0,0 +1,84 @@
+# 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.