.gitlab-ci.yml hinzugefügt.

de.bsvrz.kex.tls.zeitsync-build:

    image:

        openjdk:8-jdk-alpine

    script:

      - ./gradlew build

Versionsverlauf

===============

## [Noch nicht veröffentlicht]

## [Version 1.1.1]

- NERZ: Umstellung auf Gradle, Build durch FTB und Bereitstellung auf NERZ-Repositories

## [Version 1.1.0]

- Übernahme vor Umstellung auf Gradle

## [Version 1.0.0]

- Übernahme vor Umstellung auf Gradle

[Noch nicht veröffentlicht]: https://gitlab.nerz-ev.de/ERZ/SWE_de.bsvrz.kex.tls.zeitsync/compare/v1.1.1...HEAD

[Version 1.1.1]: https://gitlab.nerz-ev.de/ERZ/SWE_de.bsvrz.kex.tls.zeitsync/compare/v1.1.0...v1.1.1

 Hinweise zur Bearbeitung / Beteiligung

======================================

Für Änderungen an dem Projekt ist  zuerst ein Eintrag (Issue) mit dem Tag "Feature-Wunsch" oder "Bug" 

anzulegen, damit die übernommen Änderungen auch einem Problem und einer potentiell erfolgten Diskussion

zugeordnet werden können. Solange das Fehler- und Änderungsmanagement noch über die bisherigen NERZ-Bugtracker 

abgewickelt wird, ist zudem eine Referenz auf den dortigen Eintrag vorzunehmen.

Vor der Bearbeitung sollte man den entsprechenden Eintrag persönlich übernehmen

und einen Bugfix- oder Feature-Branch anlegen.

Feature-Branches werden benannt als "feature/{name}", Bugfix-Branches als "hotfix/{name}".

Der Name sollte beschreiben, was innerhalb des Branches geändert wird und **nicht den Name des Bearbeiters**.

Feature-Wünsche werden auf Basis des "develop"-Branches umgesetzt und führen letztendlich zu einem Release einer

neuen Version auf dem zweiten Level, d.h. 0.1.0 wird mindestens 0.2.0 oder in der Hauptversion, d. h. aus z. B. 1.x.y wird 2.0.0, wenn **keine** Abwärtskompatibilität besteht.

Bugfixes sollten auf dem "master"-Branch beruhen und führen zu einer neuen Version auf dem dritten Level, d.h. aus 0.1.0 wird 0.1.1.

Die Änderungen werden dann natürlich auch in den "develop"-Branch gemerged. Damit können Bugfixes kurzfristig erfolgen

ohne den Zwang gleich alle Änderungen, die sich schon im Develop-Zweig befinden mit zu veröffentlichen.

Werden im Rahmen eines Auftrags mehrere Feature-Wünsche oder Bugfixes bearbeitet, kann auch einheitlich vom "develop"-Branch gemerged werden (konkrete Abstimmung im Zweifelsfall mit der NERZ-FTB).

Branches sollten nur für einen **einzelnen Eintrag** angelegt werden.

Die Branches können nach dem Merge in den Ursprungs-Branch entfernt werden (Das Löschen erfolgt automatisch, 

wenn der entsprechende Haken beim Anlegen des Merge-Request gesetzt wird).

Ein Merge-Request sollte folgende Punkte berücksichtigen:

- die Änderungen, die mit dem Request verbunden sind sollten in kurzer prägnanter Form in das CHANGELOG-File eingetragen werden. Der Eintrag erfolgt dabei im Abschnitt "Noch nicht veröffentlicht". Die Versionsnummer wird dort erst beim Release ergänzt (also letztlich bei der Übernahme durch die NERZ-FTB).

- wenn es notwendig ist, neue Features oder Änderungen zu beschreiben muss das README-File angepasst werden

- Änderungen am Code sollten keinen auskommentierten alten Code enthalten, für den Zugriff auf die Historie ist ja GIT vorgesehen

- die bearbeiteten Einträge sollten im Kommentar für den jeweiligen Commit oder für den Merge-Request mit "Fixes #{Eintragsnummer}" um die Zuordnung zu erhalten und das automatische Schließen zu ermöglichen

**Abgelehnte Merge-Request brauchen nicht gelöscht werden!** 

Angemerkte und diskutierte Probleme, die eine Übernahme verhindern, sollten stattdessen bearbeitet werden bis der Merge-Request übernommen werden kann. **Ein neuer Request ist nicht erforderlich!**

 No newline at end of file

# SWE KEx TLS Zeitsynchronisation

## Übersicht

Diese SWE verschickt die zyklische TLS-Zeitsynchronisationstelegramme für spezifische Steuermodule über die KExTLSOsi7, wobei die zu synchronisierenden SM und die Eigenschaften der Synchronisation parametrierbar sind.

## Bemerkungen

entfällt.

## Disclaimer

Copyright (C) 2018 inovat - Dipl.-Ing. H. C. Kniß

This program is free software: you can redistribute it and/or modify

it under the terms of the GNU General Public License as published by

the Free Software Foundation, either version 3 of the License, or

(at your option) any later version.

This program is distributed in the hope that it will be useful,

but WITHOUT ANY WARRANTY; without even the implied warranty of

MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the

GNU General Public License for more details.

You should have received a copy of the GNU General Public License

along with this program.  If not, see <http://www.gnu.org/licenses/>.

Dieses Programm ist Freie Software: Sie können es unter den Bedingungen

der GNU General Public License, wie von der Free Software Foundation,

Version 3 der Lizenz oder (nach Ihrer Wahl) jeder neueren

veröffentlichten Version, weiterverbreiten und/oder modifizieren.

Dieses Programm wird in der Hoffnung, dass es nützlich sein wird, aber

OHNE JEDE GEWÄHRLEISTUNG, bereitgestellt; sogar ohne die implizite

Gewährleistung der MARKTFÄHIGKEIT oder EIGNUNG FÜR EINEN BESTIMMTEN ZWECK.

Siehe die GNU General Public License für weitere Details.

Sie sollten eine Kopie der GNU General Public License zusammen mit diesem

Programm erhalten haben. Wenn nicht, siehe <http://www.gnu.org/licenses/>.

## Kontakt

inovat, Dipl.-Ing. H. C. Kniss                                                                     

An der Krautwiese 37                                                                                     

D-53783 Eitorf                                                                                       

+49 (0)2243 8464 193                                                                                 

info@inovat.de                                                                                        

www.inovat.de