Versionsverwaltung: Parallele Entwicklung an neuen Versionen

Hallo zusammen,
ich möchte mich gerne mich mit euch austauschen wie ihr eine solch Situation handhabt auch bezüglich der Benennung der Branches.

Wir hatten bisher immer an einer nächsten Minor / Major Version gearbeitet, weshalb wir nur einen Default Branch (auch: Master / Trunk genannt) haben.

Neue Features werden in Feature Branches umgesetzt und diese werden nach Fertigstellung in den Default gemergt. Aus dem Default ensteht später der neue Stable.

Der Default hat somit eine unendliche Lebensdauer, sobald er in den Stable gemergt wird hat der Stable die neue Version und es können wieder neue Features in den Default fließen, die für das nächste Release geplant sind.
Das dürfte glaube ich überall so oder ähnlich gehandhabt werden.

Neben unseren "normalen" Releasezyklen, möchten wir nun parallel mit der Entwicklung von einem größeren Feature beginnen, das eine gänzlich neue Komponente in unserer Software darstellt. Dieses wollen wir erst in unserem Produkt haben, wenn es einen gewissen Reifeprozess hinter sich hat. Dazu arbeiten wir agil eng mit einem unserer Kunden zusammen. Dieser erhält nach Scrum Methodik auch regelmäßig Testversionen etc.

Ich stelle mir es im Moment so vor, dass es weiterhin den "normalen" Default gibt, in den die Features für das nächste Release kommen und gleichzeitig öffnen wir einen neuen Branch aus dem Default und nennen den bsw. Default-vAfterNext oder so ähnlich 😉

Wie handhabt ihr das?

VG Jens

Hallo multitasker,

öffnen wir einen neuen Branch aus dem Default und nennen den bsw. Default-vAfterNext oder so ähnlich 😉

Genau so.

Je nach Projekt bzw. neuem Feature kann es dann auch nötig bzw. angebracht sein, die Änderungen / BugFixes von master / default in den neuen Feature-Zweig zu bringen (rebase od. merge bei git).
Wenn das neue Feature davon eh unbetroffen ist so entfällt dieser Schritt.

Du kannst dir auch bei github größere Projekte anschauen wie dort mit den Branches umgegangen wird um dir Inspiration für dein Projekt zu holen.

mfG Gü

Ich stelle mir es im Moment so vor, dass es weiterhin den "normalen" Default gibt, in den die Features für das nächste Release kommen und gleichzeitig öffnen wir einen neuen Branch aus dem Default und nennen den bsw. Default-vAfterNext oder so ähnlich 😉

Halte Dich an bewährte Wege, zB. GitFlow. Dieser Flow ist typisch für Deine Vorgehensbeschreibung.

Was da vielleicht noch Interessant ist, ist die ALM Ranger Branching Guide.

DevOps (und VSTS) verfolgen den GitHubFlow, also immer sehr nahe am master Branch.
Der GitHub Flow ist eher kein Modell für die Produktentwicklung mit Jahreszyklen (zB. wie in diesem gewünschten Vorgehen beschrieben), sondern eben für Continuous Delivery.
Der GitLab Flow ist sehr fokussiert auf DevOps für komplexe Systeme.

TFVC wird für neue Projekte nicht mehr empfohlen, sondern klar git.
git ist daher auch mittlerweile default in VSTS/TFS.