AcknowledgeDocumentsRequest und -Response Typ wieder aufgenommen. Releasenotes ergänzt, ReadMe-Files umbenannt damit einheitlicher, Dokument Versionierung überarbeitet, Korrekturen am VerzeichnisOperationen.xlsx
This commit is contained in:
78
OMDSServiceDefinition/ReadMe_Release.md
Normal file
78
OMDSServiceDefinition/ReadMe_Release.md
Normal file
@@ -0,0 +1,78 @@
|
||||
# Schritte beim Release einer neuen Version
|
||||
|
||||
## Vorgehen im Git
|
||||
|
||||
Es wird das Vorgehensmodell *Git-Flow* verwendet.
|
||||
|
||||
Typischer Weise geht man vom Development-Branch aus und macht einen Release-Branch
|
||||
im Git, um die letzten Korrekturen vorzunehmen.
|
||||
|
||||
Der Release-Branch wird nach Abschluss der unten beschriebenen Schritte und
|
||||
nach Erstellung des Zips für die Veröffentlichung in den Master Branch und
|
||||
Development-Branch ge-merged.
|
||||
|
||||
Damit man den Release-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 oder unmittelbar nach dem Erstellen
|
||||
des Release-Branches den Folder für die neue Version anzulegen.
|
||||
|
||||
|
||||
## Bearbeitung der Norm
|
||||
|
||||
### 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 Dokumentenstatus soll im Kopf des Dokuments enthalten sein.
|
||||
|
||||
In der Fußzeile findet sich ein Copyright Hinweis, der ggf. aktualisiert werden muss.
|
||||
|
||||
Wenn neue Methoden veröffentlicht werden oder der Status von Dokumenten
|
||||
hochgestuft wird, dann ist die Excel-Liste mit den Methoden "VerzeichnisOperationen.xlsx" anzupassen.
|
||||
|
||||
## Versionsnummer im Pom
|
||||
Die Versionsnummer im Pom ist zu setzen, ein etwaiges "SNAPSHOT" zu streichen.
|
||||
Das Verzeichnis ist auf die richtige Versionsnummer zu setzen.
|
||||
|
||||
|
||||
## Code-Generierung
|
||||
Der Code für die neue Version ist einmalig mit Java zu generieren.
|
||||
Es gibt dazu ein Maven-Target (bei package inkludiert).
|
||||
|
||||
## 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.
|
||||
Hier ist die Versionsnummmer des Release anzupassen!
|
||||
Mit Maven "install" kann der Release gebaut werden.
|
||||
Reference in New Issue
Block a user