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!**
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
