Gute Erklärung was semantische Versionierung ist und weshalb diese benutzt wird.
Описание
Vorschlag für semantische Programmierung:
Major,Minor,Patch
Major Änderung bei Bruch des API (nicht abwärtskompatible)
Minor Änderung bei neuen Featuren ohne API Bruch
Patch Änderung bei Fehlerfixing ohne API Bruch
Um sicherzustellen, dass das API nicht gebrochen wurde wird eine Testsuite benötigt - Technical Compatibility Kits (TCK).
Wie diese TCK beschaffen sein muss und nach welchen Gesichtspunkten diese zu erstellen ist wurde leider nicht beschrieben. Aus meiner persönlichen Sicht müssen Dinge wie Parametertanzahl, ~typen und Wertebereiche für Methoden durch das TCK geprüft werden auf gültig und ungültig. Ausserdem müssten die verfügbaren Methoden je Klasse geprüft werden. Da das alles keine Fachlichkeit berührt dürfte es per Annotation generierbar sein. Allerdings sollten auch fachliche Prüfungen erfolgen (die sind dann manuell zu implementieren) z.B. ob ein persistentes Item 2 x gespeichert werden darf oder verschiedenen anderen Items zugeordnet werden darf etc. Bei korrekter Angabe von Kardinalitäten und NotNull Constraints können sogar diese Tests evtl. generiert werden.
%0 Journal Article
%1 fischer2014semantic
%A Fischer, Oliver B.
%D 2014
%J Java Magazin
%K development programming semantic tck versioning
%N 10
%P 12-13
%T Semantic Versioning - Sinn für die Versionsnummer
%U https://jaxenter.de/semantic-versioning-1034
%X Gute Erklärung was semantische Versionierung ist und weshalb diese benutzt wird.
@article{fischer2014semantic,
abstract = {Gute Erklärung was semantische Versionierung ist und weshalb diese benutzt wird.},
added-at = {2015-03-06T15:06:48.000+0100},
author = {Fischer, Oliver B.},
biburl = {https://www.bibsonomy.org/bibtex/24ed78aca95d78e6093574f0e41920be8/funthomas424242},
description = {Vorschlag für semantische Programmierung:
Major,Minor,Patch
Major Änderung bei Bruch des API (nicht abwärtskompatible)
Minor Änderung bei neuen Featuren ohne API Bruch
Patch Änderung bei Fehlerfixing ohne API Bruch
Um sicherzustellen, dass das API nicht gebrochen wurde wird eine Testsuite benötigt - Technical Compatibility Kits (TCK).
Wie diese TCK beschaffen sein muss und nach welchen Gesichtspunkten diese zu erstellen ist wurde leider nicht beschrieben. Aus meiner persönlichen Sicht müssen Dinge wie Parametertanzahl, ~typen und Wertebereiche für Methoden durch das TCK geprüft werden auf gültig und ungültig. Ausserdem müssten die verfügbaren Methoden je Klasse geprüft werden. Da das alles keine Fachlichkeit berührt dürfte es per Annotation generierbar sein. Allerdings sollten auch fachliche Prüfungen erfolgen (die sind dann manuell zu implementieren) z.B. ob ein persistentes Item 2 x gespeichert werden darf oder verschiedenen anderen Items zugeordnet werden darf etc. Bei korrekter Angabe von Kardinalitäten und NotNull Constraints können sogar diese Tests evtl. generiert werden.},
interhash = {67b3fff2986233d26dbdd6f2335461fa},
intrahash = {4ed78aca95d78e6093574f0e41920be8},
journal = {Java Magazin},
keywords = {development programming semantic tck versioning},
number = 10,
pages = {12-13},
timestamp = {2015-03-06T16:40:02.000+0100},
title = {Semantic Versioning - Sinn für die Versionsnummer},
url = {https://jaxenter.de/semantic-versioning-1034},
year = 2014
}