Derzeit verwenden wir das folgende Versionsnummernschema für unser C # winforms-Projekt:
"Major Release". "Minor Release". "Iterationsnummer". "Build Nummer innerhalb dieser Iteration"
Wir wollten in der Lage sein, die Iterationsnummer und die Build-Nummer innerhalb dieser Iteration zu identifizieren, indem Sie einfach die Versionsnummer betrachten.
In der Vergangenheit hatten wir etwas wie "Major Release" gemacht. "Minor Release". "Sequential Build Number from 1.0". Zum Beispiel würde "4.0.648" bedeuten, dass es 648 Builds seit 1.0 gab - aber diese Information ist ziemlich nutzlos und anekdotisch, weshalb wir geändert haben, um Iterationen und Builds innerhalb von Iterationen widerzuspiegeln.
Angesichts dieser neuen agilen Versionsnummerierung haben wir nun das Problem, dass eine andere Produktgruppe Änderungen in ihrer Iteration für unser Projekt vornehmen möchte. In diesem Fall wäre die Versionsnummer nicht sinnvoll, da ihre Iterations- und Build-Nummern nicht übereinstimmen. Zum Beispiel war der letzte Build meines Projekts 1.0.5.1, der den ersten Build von Iteration 5 anzeigt. Jetzt möchte dieses andere Projekt, das in seiner dritten Iteration Änderungen an meinem Projekt und dem Wiederaufbau vornehmen möchte.
Wie soll ich mit dieser Situation umgehen? Wie machen Sie die Versionsnummerierung in Ihrem agilen Projekt?
Ich verfolge die Iteration der agilen Projekte, nicht die Iteration der Softwareprojekte. Wenn ein spätes Starter-Projekt nach einem anderen Projekt eintritt, wird es daher mit der aktuellen agilen Projekt-Iteration starten, und es wird keine Fehlausrichtung geben.
Es sollte nicht möglich sein, dass ein technisches Projekt außerhalb der agilen Projektdomäne mit einem Projekt innerhalb der Domäne interagiert. Das wäre ein PM-Fehler des Prozesses und sollte in allen Fällen eliminiert werden, in denen eine gemeinsam genutzte Codebasis mit Verzweigung verwendet wird, die nach Abschluss des Projekts als Bereinigungsschritt in den Hauptpfad gepatcht wird.
Persönlich denke ich, dass die Release-Version, die mir am besten gefallen hat, darin besteht, das ganze major.minor -Stück ganz abzuschaffen. Ich denke, das ist nur für interne Anwendungen wirklich machbar, aber dafür macht es das Leben viel einfacher.
Wenn Sie Anwendungen entwickeln, die auf sich selbst ausgerichtet sind, habe ich bemerkt, dass das Unternehmen sich eigentlich nicht wirklich darum kümmert, welche Haupt- / Nebenversion sie verwenden. Stattdessen neigen sie dazu, a) wann ist die nächste Veröffentlichung und b) was wird in oder aus sein - und das ist es. Der Versuch, die Tatsache, dass du an FOO-4.34.0.1-a und BAR-3.19.4.1 arbeitest, wenn niemand interessiert, dient nur dazu, die Kommunikation zu erschweren.
In einer früheren Gruppe hatten wir außer einem Projektstart eigentlich keine größeren Veröffentlichungen. Jede Veröffentlichung war so "wichtig" wie die vorherige.
Ich denke, dass sie das Vernünftige getan haben und stattdessen dem Unternehmen als PROJECT_RELEASENUM mitgeteilt haben. Die Versionsnummer wurde bei jeder Veröffentlichung um 1 erhöht, mit Patches als PROJECT_RELEASENUM_PATCHNUM , die ebenfalls um '1' erhöht wurden.
Es funktioniert gut mit der Vorstellung, dass Entwicklung als eine kontinuierliche Reihe von Sprints durchgeführt wird, bis das Unternehmen alle Funktionen hat, die sie brauchen (was in der Praxis nie passiert - es gibt immer etwas mehr als sie wollen). Geschäftsinhaber haben es verstanden, Entwickler konnten es kommunizieren, und es hat sich natürlich für das kontinuierliche Entwicklungsmodell, das wir hatten, gelohnt.
Ich bevorzuge Major.Minor.Build.Revision wo Build - die Anzahl der öffentlichen Releases, Revision - eine Revision vom Quellversionssystem
Ich bevorzuge es, den Build- und Release-Prozess vom Teamentwicklungsprozess zu trennen, sodass ich der Version kaum die Iteration, Sprint oder Ähnliches hinzufügen würde. Ihr Fall ist ein gutes Beispiel dafür, dass es nicht einfach ist, beide Dinge gemischt zu haben. Was passiert, wenn Sie die Methodik in der Mitte des Projekts ändern (was auch immer der Grund sein mag)?
Als Antwort auf Ihre Frage verwenden wir seit zwei Jahren Scrum und unser Versionsformat ist das klassische Major.Minor.Upgrade.Build (wir verwenden nur das Upgrade auf Bugfixes). Am Ende ist es nicht zwingend erforderlich, die Build-Nummer zu verwenden, da sie nur benötigt wird, um verschiedene Pakete von derselben Version zu unterscheiden, aber Sie können ein anderes Symbol verwenden, das eine Art von privater Version darstellt.
Tags und Links c# agile versioning