Versionierungsverfahren für modulare Programme

[jobo]

Hallo,

ich habe eine allgemeine Frage zur Handhabung, Darstellung und Kontrolle von Versionsnummern in einem Projekt, das mit mehreren Modulen arbeitet. Primär geht es dabei nicht um die Entwicklungswerkzeuge, sondern um die Perspektive Support/Endanwender. Aktuell handelt es sich um eine .NET Anwendung, die mehere Assemblies nutzt (auch dynamisch) und ein DB-Backend mit wachsenden Modell Versionen. Die Problematik ergibt sich aber unabhängig von .NET.

Aus der Delphientwicklung ist man ja meist eine monolithische Anwendung gewohnt. Man hat also auch nur eine Versionsnummer, die ziemlich simpel mit deployed wird und schon im Explorer abgefragt werden kann. Oft kommt dann eben noch eine weitere Versionsnummer aus dem DB Backend dazu. Das ist überschaubar.

Kommen neben einer Kernanwendung mehrere Module- evtl. auch dynamisch-hinzu, so hat jedes einzelne eine Version.
Der Anwender oder Support Team bekommt primär natürlich nachwievor eine Hauptversion zu sehen. Ein Bugfix in einer DLL (die auch einzeln ausgeliefert wird) geht dabei leicht unter.
Wir verwenden bereits eine Funktion, die geladene Assemblies auflistet und dazu deren Versionsnummern angibt. Übersichtlich ist das aber noch nicht, allein schon die Frage der Vollständigkeit ist damit nicht geregelt.

Ließe sich eine Hauptversionierung erreichen, die nicht 20 Stellen hat und trotzdem kleinste Unterschiede wiedergibt?
Wie kann man den "Rang" eines Moduls in eine Versionierung bringen (Kernkomponente, Fachkomponente)

Die Thematik betrifft einerseits den Endanwender, andererseits aber schon die Entwicklungsphase, Betastadium, Testing.

Vielen Dank schonmal für Erfahrungen und Vorschläge.

P.S.: Auch wenn es am Ende um ein konkretes .NET Projekt geht, hab ich das erstmal unter "allgemein" eingestellt. Vielleicht muss es verschoben oder woanders vertieft werden

[CCRDude]

Ich bin mir nicht ganz sicher, ob ich das Problem verstehe; ich kann ja kurz beschreiben, wie wir das mit unseren Modulen machen.

Zum einen nehmen wir das Build Date. Unser Build Skript (momentan noch FinalBuilder) aktualisiert die Versionsresourcen jedes Moduls vor dem Kompilieren um ein benutzerdefiniertes Feld mit eben jenem. Das ist unsere 8-stellige "Hauptrevisionsnummer".

Weiterhin haben wir zwei Repositories (allgemeiner & projektspezifischer Code). Jedes Build hat damit zwei weitere VCS-Revisionen, die es eindeutig bezeichnen. Da unser Ticket-System auch Verweise auf das VCS enthält, bzw. unser VCS Verweise auf das Ticket-System, lässt sich hier klar unterscheiden.

Daneben verwenden wir noch VCS-Tags für jeden Milestone, der ein komplett getestetes (also an den Kunden herausgebbares) Release enthält.

Unsere Fensteroberklasse sorgt für einen About-Dialog im Systemmenü jedes Fensters, der diese Informationen automatisch anzeigt; in Debug-Versionen werden Sie auch an den Fenstertitel angehängt.

Damit sind wir bisher gut gefahren. Wenn wir allerdings mal einzelne Dateien ans Testteam geben, läuft die Kommunikation nur über das Auto-Inkrement-Build-Feld nach Delphi.

[jobo]

So ähnlich arbeiten wir auch, naja, Ansichtssache.
Wir haben keine Systeminfo je Fenster. Die GUI Architektur stellt optisch überhaupt keine separaten Fenster dar, sieht eher wie ein klassischer Explorer aus. Technisch sind es allerdings verschiedene Forms.

Wie darf ich mir das bei Euch unter Delphi vorstellen? MDI Anwendung und pro Fenster eine eincompilierte DCU? Oder liefert Ihr auch separate DLL aus?

Wir setzen unter .Net die Buildnummer nicht ein. Die MS Philosophie für die Buildnummern in .net ist mir auch nicht ganz einleuchtend.
Da wir Programmmodule nur bei Bedarf neu erstellen, verwalten wir separat statt des Builds noch eine Dateiversion pro Assembly projektübergreifend. Hier tragen wir eine durchgängige Nummer je Release ein. Die Buildnummer bleibt erhalten, solange sich der Code nicht ändert. Aus fachlicher Perspektive hat und braucht dann gar nicht jeder Anwender alle Assemblies.

Framework (Core Assembly), externe Assemblies und fachliche Assemblies sind also mehr oder weniger autark. Es gibt kein gemeinsames Build. Dabei ist es gewollt, dass einzelne Module nur nach Bedarf erweitert und deployed werden.

Im Backend verwenden wir GIT. Hier arbeiten wir auch mit tags für die Releases/Revisionen, aber die Sourceversionierung steht für mich hier nicht im Vordergrund. Es geht eher darum, wie man eine smarte Kontrolle der aktuellen/notwendigen Dateiversionen durchführt. Und wie könnte sowas automatisch in das Setup einfließen?

Am Ende hätte ich gerne trotz unterschiedlich breiter Deployments >eine< klassische Programmversion, wenigstens optisch. Hier würde ich mir aber anstelle der Buildnummer eher eine Art Prüfsumme vorstellen- je nachdem, welche Module geladen sind. Damit wäre allein die Programmversion beim Testing und für den Support schon wesentlich aussagekräftiger.
Mag sein, dass das unkonventionell ist. Aber ich krieg da einfach keinen besseren Dreh rein.

[BUG]

Sind immer alle Plugins beim Kunden auf dem gleichen (zeitlichem) Stand und es gibt nur einen Entwicklungszweig?

Idee (also nicht erprobt, usw.):

Du könntest bei jedem Release eines Gesamtpackets eine neue Versionsnummer herausgeben,
also quasi die Versionen versionieren.

zB:

Gesamtversion: 1.0
Badezimmerschrank (Kernmodul) 1
Badezimmerspiegel (Kernmodul) 1
Puderdose 1
Rasierapperat 1

Gesamtversion: 1.1
Badezimmerschrank (Kernmodul) 1
Badezimmerspiegel (Kernmodul) 1
Puderdose 2
Rasierapperat 1

Gesamtversion: 1.2
Badezimmerschrank (Kernmodul) 1
Badezimmerspiegel (Kernmodul) 1
Puderdose 2
Rasierapperat 2


Gesamtversion: 2.0
Badezimmerschrank (Kernmodul) 2
Badezimmerspiegel (Kernmodul) 1
Puderdose 2
Rasierapperat 2


Die Versionsnummer, die der Kunde sieht, ist die niedrigstmögliche Gesamtversion.
Für Spezialversionen könnten man dann doch die geänderte Module als Text anhängen und eventuell noch eine kleines Merkmal in der Nummer, das der Support das sieht und nachfragen kann.

[jobo]

Hallo Bug!

Zitat:

Zitat von BUG (Beitrag 1146718)

Sind immer alle Plugins beim Kunden auf dem gleichen (zeitlichem) Stand und es gibt nur einen Entwicklungszweig?

Nein, wir haben ein E und ein Q System und der Kunde auch (Q und P). Wenn man uns selbst mal außen vor lässt, gibt es beim Kunden also 2 Versionen. Außerdem kann es Anwender geben, die im Produktivsystem noch kein Upgrade bekommen haben. (Weil sie in einer anderen "Gruppe" sind)
Offiziell gibt es nur einen Entwicklungszweig, es kommt aber eine sqLite Variante, es gibt ein 32 und 64 bit Setup, das aber lediglich Umgebungsparameter variiert.

Zitat:

Zitat von BUG (Beitrag 1146718)

Du könntest bei jedem Release eines Gesamtpackets eine neue Versionsnummer herausgeben,

Es gibt ja kein "Gesamtpaket". Oder es ist eben die Frage wie man das nennt.
Auch wenn ein Neuanwender eine Version bspw. 2.1 als Neuinstallation erhält, ist es für einen Altanwender technisch nur das Upgrade von sagen wir 3 assemblies. Formal ist es in beiden Fällen das nächste Release.

Zitat:

Zitat von BUG (Beitrag 1146718)

Die Versionsnummer, die der Kunde sieht, ist die niedrigstmögliche Gesamtversion.

Der Satz gefällt mir, aber ich würde es lieber so haben:
Die Versionsnummer, die der Kunde sieht (und der Support), ist immer die genaueste.

Das Thema hat viele verschiedene Aspekte. U.a. was leistet ein Installer oder ein anderer an der Stelle?
Ich hab mich noch nie mit MSI beschäftigt, aber vielleicht geht da ja was. Beim hauseigenen Buildhandling von .NET sieht das allerdings auch eher Bescheiden aus. Aber vlt ist die Buildversion eben auch gar nicht der richtige Aufhänger dafür.