Merge branch 'GradleUmstellung' into 'develop'

# Created by .ignore support plugin (hsz.mobi)

### Maven template

target/

pom.xml.tag

pom.xml.releaseBackup

pom.xml.versionsBackup

pom.xml.next

release.properties

dependency-reduced-pom.xml

buildNumber.properties

.mvn/timing.properties

### JetBrains template

# Covers JetBrains IDEs: IntelliJ, RubyMine, PhpStorm, AppCode, PyCharm, CLion, Android Studio

*.iml

## Directory-based project format:

.idea/

# if you remove the above rule, at least ignore the following:

# User-specific stuff:

# .idea/workspace.xml

# .idea/tasks.xml

# .idea/dictionaries

# Sensitive or high-churn files:

# .idea/dataSources.ids

# .idea/dataSources.xml

# .idea/sqlDataSources.xml

# .idea/dynamic.xml

# .idea/uiDesigner.xml

# Gradle:

# .idea/gradle.xml

# .idea/libraries

# Mongo Explorer plugin:

# .idea/mongoSettings.xml

## File-based project format:

*.ipr

*.iws

## Plugin-specific files:

# IntelliJ

/out/

# mpeltonen/sbt-idea plugin

.idea_modules/

# JIRA plugin

atlassian-ide-plugin.xml

# Crashlytics plugin (for Android Studio and IntelliJ)

com_crashlytics_export_strings.xml

crashlytics.properties

crashlytics-build.properties

### Eclipse template

*.pydevproject

.metadata

.gradle

bin/

tmp/

*.tmp

*.bak

*.swp

*~.nib

local.properties

.settings/

.loadpath

# Eclipse Core

.project

build.properties

# Eclipse Checkstyle

.checkstyle

# External tool builders

.externalToolBuilders/

# Locally stored "Eclipse launch configurations"

*.launch

# CDT-specific

.cproject

# JDT-specific (Eclipse Java Development Tools)

.classpath

# Java annotation processor (APT)

.factorypath

# PDT-specific

.buildpath

# sbteclipse plugin

.target

# TeXlipse plugin

.texlipse

# Eclipse Findbugs

.fbExcludeFilterFile

/debug/

/TmpFiles*/

dua-progglaette-build:

    image:

        openjdk:8-jdk-alpine

    script:

      - ./gradlew build -x test

language: java

jdk:

  - oraclejdk8

install: true

script: mvn -DskipTests install -B -V

Versionsverlauf

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

## [Noch nicht veröffentlicht]

## [Version 2.0.4]

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

## Version 2.0.3

- Applikationsname für MessageSender entsprechend NERZ-Vorgabe gesetzt

## Version 2.0.2

Release-Datum: 28.07.2016

de.bsvrz.dua.progglaette.tests.DuAProgGlaetteTestBase

- der Member "_glaetteWarnungUndPrognose" sollte nicht statisch sein, der er bei jedem Test neu initialisiert wird

- Javadoc für Java8-Kompatibilität korrigiert

- Obsolete SVN-Tags aus Kommentaren entfernt

- Obsolete inheritDoc-Kommentare entfernt

## Version 2.0.1

Release-Datum: 22.07.2016

- Umpacketierung gemäß NERZ-Konvention

## Version 2.0.0

Release-Datum: 31.05.2016

### Neue Abhängigkeiten

Die SWE benötigt nun das Distributionspaket de.bsvrz.sys.funclib.bitctrl.dua

in Mindestversion 1.5.0 und de.bsvrz.sys.funclib.bitctrl in Mindestversion 1.4.0,

sowie die Kernsoftware in Mindestversion 3.8.0.

### Änderungen

Folgende Änderungen gegenüber vorhergehenden Versionen wurden durchgeführt:

- Ist kein Taupunkttemperatursensor vorhanden oder liefert dieser keine gültigen

  Daten, dann wird stattdessen die berechnete Taupunkttemperatur-Fahrbahn aus

  der Datenaufbereitung verwendet.

### Fehlerkorrekturen

Folgende Fehler gegenüber vorhergehenden Versionen wurden korrigiert:

- Tippfehler in Warnmeldung: Fehler bei der Initialisierung des EntscheidunsBaumes.

## Version 1.4.0

- Umstellung auf Java 8 und UTF-8

## Version 1.3.0

- Umstellung auf Funclib-BitCtrl-Dua

## Version 1.2.0

- Umstellung auf Maven-Build

- Behandlung nicht unterstützter Sensorarten über die 'UmfeldDatenSensorUnbekannteDatenartException'

- benötigt SWE_de.bsvrz.sys.funclib.bitctrl_FREI_V1.2.3.zip oder höher 

## Version 1.0.1

- Bash-Startskript hinzu

## Version 1.0.0

- Erste Auslieferung

[Noch nicht veröffentlicht]: https://gitlab.nerz-ev.de/ERZ/SWE_de.bsvrz.dua.progglaette/compare/v2.0.4...HEAD

[Version 2.0.4]:

https://gitlab.nerz-ev.de/ERZ/SWE_de.bsvrz.dua.progglaette/compare/v2.0.3...v2.0.4

` 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