nicht angemeldet
Konzept für Versionierung
Hallo,
wir brauchen ein möglichst zukunftssicheres und flexibles Versionierungskonzept. Hier hab ich mal eins, anhand von konzeptionellen Klassen erstellt. Hoffe nun
etwas Kritik zu erhalten!
// enum gibt alle möglichen Anwendungen an z. B. Word, Excel, Powerpoint...
public enum Application
{
ApplicationName1,
ApplicationName2,
ApplicationnameN
}
// enum gibt alle möglichen Updates an, die von der Entwicklungsabteilung erstellt werden könnten
public enum UpdateType
{
SecurityPatch,
CriticalUpdate,
Update,
Hotfix,
Updaterollup,
ServicePack,
IntegratedServicePack,
FeaturePack
}
// Ist einer (installierten) Anwendung direkt zugeordnet
public class ApplicationVersion
{
Application applicationName;
int MajorNumber;
int MinorNumber;
UpdateType[] includedUpdates; // Liste die alle Updates enthält, die der Anwendung installiert wurden
}
// spezifiziert den Typ des Updates, sowie alle kompatiblen Anwendungen
public class UpdateVersion
{
ID fortlaufendeID;
UpdateType updateType;
ApplicationName applicationName; // Damit das Update einer bestimmten Anwendung zugeordnet werden kann
ApplicationVersion[] compatibleApplications; // Liste mit kompatiblen Anwendungen (bestimmen die Entwickler)
}
Gruß
-
Moin!
wir brauchen ein möglichst zukunftssicheres und flexibles Versionierungskonzept. Hier hab ich mal eins, anhand von konzeptionellen Klassen erstellt. Hoffe nun etwas Kritik zu erhalten!
Kritik: Was willst du eigentlich tun?
- Sven Rautenberg
-
Wir benötigen ein Versionierungskonzept, da wir ein neues Updateverfahren einführen möchten. Unser Unternehmen entwickelt mehrere verschiedene Anwendungen, sowie verschiedene Typen von Updates.
Das bekante Schema (nachzulesen bei Wiki) mit MajorNumber.MinorNumber.PatchLevel.BuildNumber finde ich nicht gut. Denn wenn eine Anwendung z. B. die Versionsnummer 4.5.5.6 sagt das NIX darüber aus, welche Updates installeirt sind und welche nicht. Uns reichen eigentlich die MajorNumber und die MniorNumber aus. Darüberhinaus wird eben eine Datenstruktur benötigt, die alle installierten Updates enthält. Die Updates wiederum können eine Datenstruktur enthalten, die alle kompatiblen Anwendungen beschreibt.
Gruß
-
Moin!
Wir benötigen ein Versionierungskonzept, da wir ein neues Updateverfahren einführen möchten. Unser Unternehmen entwickelt mehrere verschiedene Anwendungen, sowie verschiedene Typen von Updates.
Du suchst anscheinend kein Versionierungskonzept (das würde sich nämlich auf Versionsverwaltungssoftware wie CVS, Subversion etc. beziehen), sondern ein Versionsnummernkonzept.
Das bekante Schema (nachzulesen bei Wiki) mit MajorNumber.MinorNumber.PatchLevel.BuildNumber finde ich nicht gut. Denn wenn eine Anwendung z. B. die Versionsnummer 4.5.5.6 sagt das NIX darüber aus, welche Updates installeirt sind und welche nicht.
Wenn das bei eurer Software so ist, ist das schlecht. Nehme ich zum Beispiel den Browser Opera her, dann ist mit der Angabe "Version 9.63, Build 10476" alles exakt ausgesagt. Eigentlich ist sogar nur die Buildnummer entscheidend, der Rest der Versionsnummer ist aus organisatorischen und aus Marketinggründen vorhanden.
Uns reichen eigentlich die MajorNumber und die MniorNumber aus.
Diese beiden Zahlen sind heutzutage aus puren Marketinggründen vorhanden und haben nach meiner Auffassung eigentlich keinerlei sachliche Aussagekraft.
Die üblichen Versionsverwaltungssysteme weisen jedem Checkin eine generierte Versionsnummer zu, bei Subversion beispielsweise eine fortlaufend inkrementierte Ganzzahl. Diese Changeset-Nummer gilt global für das gesamte betroffene Repository, dementsprechend bezieht sie sich auch auf die aus den Quelltexten dieses Changesets gebaute Software. Die Software hat also die Versionsnummer des Changesets. Wenn Marketing- und Ordnungsleute dem dann noch eine wohlklingende Major.Minor-Nummer geben wollen, hat das mit der Softwareorganisation nicht so viel zu tun.
Darüberhinaus wird eben eine Datenstruktur benötigt, die alle installierten Updates enthält. Die Updates wiederum können eine Datenstruktur enthalten, die alle kompatiblen Anwendungen beschreibt.
Und du glaubst, dass du hier ohne Angabe von Details hilfreiche Kritik erhältst?
Meine Kritik: Wenn es Probleme mit einem komplexen Updatesystem gibt, dann sollte man mal vorbehaltlos dieses Updatesystem einer drastischen Schlankheitskur unterziehen. Wenn es eine Software gibt, deren diverse Installationen es erlauben, dass die Zahl der möglichen installierten Update-Permutationen größer ist als die Zahl der Codezeilen, dann läuft da was falsch - weil kein vernünftiger Mensch solch einen komplexen Zirkus noch vernünftig supporten kann.
- Sven Rautenberg
-
Hallo Sven, vielen Dank für deine Hilfe! Ich denke du hast Recht, ich hab mir ein wesentlich einfacheres Konzept überlegt, das dem bisherigen ähnelt.
Gruß
-
-
-