Suche Versionierungsstrategie für ... Projektumbau

[Der schöne Günther]

Liebe Gemeinde, ich brauche Rat.

Wir versionieren unsere Software mit Mercurial, das sollte hier eigentlich deckungsgleich mit Git sein. Eine alte SVN-Gewohnheit haben wir beibehalten: Named Feature Branches welche i.d.R. immer ins zentrale Repo übernommen werden. Nur noch schnell als Bildchen:
SharedImage.jpg

Meine Geschichte ist folgende: Eine Software ist über lange, lange Zeit gewachsen und wird momentan runderneuert, vieles wird neu geschrieben. Bestehender Code wird für gewöhnlich nicht mehr groß umgewälzt, sondern nur durch neuen ersetzt oder entfernt.

So weit, so gut. Das kniffelige: Die bestehende Software ist nicht eingeschlafen, sie wird (unter oben abgebildetem Modell) stetig weiterentwickelt, neue Features kommen hinzu. Währenddessen bildet die "neue" Software mittlerweile schon ein eigenes Produkt, beide werden eine Zeit lang parallel vertrieben werden.

Ich will mit meinen Umbauarbeiten nicht in die Arbeiten der „alten Software“ reingrätschen. Deshalb suche ich mir ein Release (z.B. "1.1") und baue darauf auf: Mit Patches (also mutable changesets). Alle paar Wochen baue ich die Patches ab, wechsele auf das neuste Release und spiele die Patches wieder drauf. Das klappt natürlich nicht reibungslos da sich in der "alten Software" Dinge geändert haben. Für die Anpassungen daran benötige ich dann zwischen 30 und 120 Minuten, das ist kein Problem. Dann habe ich die „neue Software“ auf Basis der Features von z.B. „Release 1.2“.

Mein Problem hierbei: Die „neue Software“ nähert sich dem Punkt an welchem sie regulär angeboten werden soll. Und ich habe mit meinen Patch Queues keine feste Historie an denen ich in ein paar Monaten sagen könnte „Das ist Version XY, die wurde an Kunden A, B und C ausgeliefert“. Ich brauche Snapshots.

Das einzige was mir einfällt: In Mercurial kann man seine Patch-Queues wiederrum versionieren, denn die sind im Endeffekt in eigenes Repository. Vom Komfort her ist das aber wirklich Welten von unserem gewohnten, oben abgebildeten Modell entfernt. Da kann man glasklar sehen welche Features und Fixes in welchem zeitlichen Verlauf reinkamen und wie ein Feature entwickelt wurde.

Was gibt es für Alternativen? Die „Weiterentwicklung“ als einen einfachen Zweig im Repo zu betreiben traue ich mich schlichtweg nicht – Ich glaube nicht dass man ein groß angelegtes Refactoring betreiben kann und nachträglich immer wieder Änderungen aus dem „un-refactorten“ Teil übernehmen ohne dass sich da alles durcheinander würfelt.


Ich danke fürs Lesen und wünsche ein schönes Wochenende.