This is an old revision of the document!


Sourcecodeverwaltung

Wir entwickeln Admidio mit Hilfe der Versionsverwaltung Git auf der Plattform GitHub. Der aktuelle Sourcecode befindet sich im sogenannten Master Branch und ist über folgenden Link zu finden:

https://github.com/Admidio/admidio

GitHub bietet außerdem einen Client für https://mac.github.com/Mac und Windows an.

Der Master Branch beinhaltet den Code der letzten Stabilen Version und zusätzlich alle stabilen Erweiterungen, die seit dem letzten Release hinzugekommen sind. Falls du Admidio weiterentwickeln willst, empfehlen wir dir diesen Branch als Basis zu nehmen. Idealerweise erstellst du dann von diesem Branch in deinem GitHub Account einen Fork. Dort kannst du nun deine Erweiterung entwickeln und in den Fork commiten. Sobald deine Erweiterung fertig ist, kannst du einen Pull Request für unseren Master Branch erstellen. Diesen werden wir uns dann anschauen und besprechen um ihn dann im Idealfall zu übernehmen.

Kurz nachdem wir eine neue Hauptversion veröffentlicht haben, erstellen wir einen sogenannten Branch speziell zu dieser Version. Hier wird praktisch der aktuelle Entwicklungsstand passend zur veröffentlichten Version festgehalten. Auf diesem Entwicklungsstand können wir dann später Korrekturen einspielen unabhängig davon, was parallel im Trunk weiter entwickelt wurde. Der Branch ist bei uns immer passend zu einer Version. Am Namen des Branches kann man erkennen, welche Version hinter welchem Branch steckt. Beispiel für Admidio 2.4 ist der Branchname v2.4 den du unter folgender URL erreichst:

https://github.com/Admidio/admidio/tree/v2.4

Schreibrechte für Subversion erhalten bei uns alle Teammitglieder. Allerdings sollten beim Einchecken gewisse Regeln beachtet werden. Zum einen sollte der Sourcecode unseren Programmierrichtlinien entsprechen und zum anderen sollte immer ein konsistenter Stand eingecheckt werden. Ein neues Feature muss zwar nicht direkt vollständig und funktionsfähig eingecheckt werden, aber es sollten keine Fehler mehr enthalten sein, die ganze Bereiche nicht mehr anwendbar machen. Neue Funktionen sollten vorher in unserem Feature Tracker eingestellt und beschrieben werden.
Außerdem sollte beim Einchecken (Commit) eine beschreibender Satz angegeben werden, wenn möglich mit einem Verweis zu dem Feature-/Bug-Tracker. Dies könnte dann so aussehen:

BUG#472 Eingegebene Daten werden bei einer Navigation zurück ignoriert
FRE#506 Beziehungen zwischen Mitgliedern können gepflegt werden

Sollte der eingecheckte Sourcecode nicht den Kriterien entsprechen, kann er auch wieder entfernt werden und das Schreibrecht entzogen werden. Dies ist aber bisher noch nicht nötig gewesen und lässt sich i.d.R. auch ohne die angedrohten Maßnahmen regeln.

Wird ein Fehler in der aktuellen veröffentlichten Version gefunden, so muss dieser im Branch und im Trunk behoben werden. Der Branch sollte in diesem Fall der veröffentlichten Version entsprechen und im Trunk (aktuelle Entwicklung der nächsten Version) muss geschaut werden, ob der Fehler noch vorhanden ist und ggf. auch korrigiert werden.

Ein einfaches kopieren der Datei vom Branch in den Trunk oder andersherum eignet sich in den meisten Fällen nicht, da im Trunk die Entwicklung schon längst weitergelaufen sein könnte und die Datei dann nicht mehr zum Sourcecode des Branchs passen würde. Sind die Dateien (Branch/Trunk) unterschiedlich, so muss der Fehler 2x korrigiert werden. Nur wenn man sich absolut sicher ist, dass keine Unterschiede zwischen dem Branch und Trunk in den betroffenen Dateien existieren, so kann man den Fehler 1x korrigieren und die Datei dann in das andere System kopieren.

  • de/entwickler/fehlerkorrekturen_in_mehreren_versionen.1421491381.txt.gz
  • Last modified: 2015/01/17 11:43
  • by fasse