Branches/de
From OpenSimulator
 |
Languages: |
|
Contents |
Zweige und Tags im Git Repo
OpenSimulator verwendet Git für sein Quellcode-Repository. Das Repository enthält verschiedene Zweige und Tags, die zur Identifizierung von Entwicklungszweigen und Releasezweigen des Codes verwendet werden. Das primäre Git-Repository wird auf der Domäne opensimulator.org gehostet. Auf Github wird ein Spiegel gepflegt. Das Github-Repo wird alle 10 Minuten mit dem primären Repo synchronisiert.
Git Repos
- Primary OpenSimulator Git Repo
- Mirror OpenSimulator Github Repo
- Mirror OpenSimulator Bitbucket Repo
- libOpenMetaverse for OpenSimulator – unser Fork von libOpenMetaverse
Repositorys im primären Git
- opensim – der OpenSimulator Quellcode
- opensim-libs – Zweige von Bibliotheken Dritter, die beim Erstellen von OpenSimulator verwendet werden
Auf dieser Seite werden die Zweige und Tags des Repositorys beschrieben. wofür sie gedacht sind, und unsere Richtlinien für das, was darin enthalten ist.
Lesen Sie auch
Branches
master
Der Master-Zweig verfügt über die neueste OpenSimulator-Entwicklung.
OpenSimulator Master Branch Richtlinien
- Master is not guaranteed to function. It might be in the middle of a transition, or undergoing a major overhaul.
- Master should always build
- All tests should run green on trunk
- Code should have been reasonably tested
- Es kann nicht garantiert werden, dass der Master funktioniert. Möglicherweise befindet es sich mitten in einer Umstellung oder in einer umfassenden Überarbeitung.
- Der Master Zweig sollte immer bauen
- Alle Tests sollten am Stamm grün laufen
- Der Code hätte angemessen getestet werden müssen
Durchsuchen desn Hauptzweiges
Neue Hauptveröffentlichungen
Für den Hauptmastercode wird ein neues Release erstellt.
- Ein Tag mit der Vollversion wird hinzugefügt. (Beispiel 0.9.1.1).
- Es wird ein Branch mit dem Namen der Release-Nummer erstellt.
- Die Master-Version wird mindestens auf die nächste Minor-Nummer geändert.
Neue Nebenveröffentlichungen
Nebenversionen enthalten kleine Änderungen oder Korrekturen gegenüber der vorherigen Version.
In vielen Fällen entspricht der Master-Zweig der erforderlichen Version. In diesem Fall handelt es sich lediglich um eine neue Version.
Gelegentlich kann es erforderlich sein, nur ausgewählte Commits oder sogar einzigartigen Spezialcode einzuschließen, in diesem Fall:
- Wechsel (Auschecken) zum Zweig des Releases, der repariert werden soll (oder Tag im Hauptzweig)
- Erhöhen Sie die Nebenversionsnummer(n).
- Erstellen Sie einen neuen Zweig mit dem Namen dieser Version.
- Führen Sie die Korrekturen durch
- release
Kandidaten freigeben
Release-Kandidaten sollten, außer aus besonderen Gründen, lediglich Schnappschüsse des Hauptcodes sein sie dürfen höchstens einen TAG enthalten.
Altes Verfahren (vor Version 0,9x)
Bei der alten Prozedur wurden nach dem Versionsnamen zusätzliche Namen wie „-Release“ und „-postfixes“ verwendet.
Alle Veröffentlichungen sollten eine eigene Versionsnummer haben.
Die unteren Ziffern eines Versionsnamens sind klar und bieten eine ausreichende Identifizierung für kleinere Änderungen und Fehlerbehebungen.
So etwas wie 0.7.0.1-Release und 0.7.0.1-Post-Fixes war einfach überflüssig und verwirrend.
Im neuen Format wären dies nur 0.7.0.1 und 0.7. 0,2
Other Branches
Andere Zweige enthalten hauptsächlich temporäre Entwicklungsarbeiten, beispielsweise um neuen Code zu entwickeln, ohne den aktuellen Master zu stören
Durchsuchen Sie eine Liste aller Filialen
Tags
Ursprünglich wurden Tags verwendet, um den automatischen Release-Erstellungsprozess auszulösen. Als es Zeit für eine Veröffentlichung war, wurde ein <version>-release-Tag auf einen Zweig angewendet, wodurch der automatisierte Prozess ausgelöst wurde, der die Release-Tarballs erstellte. Weitere Einzelheiten finden Sie unter Automatisierte Release-Erstellung . Tags werden weiterhin zur Kennzeichnung von Veröffentlichungen verwendet, können aber auch für andere Zwecke verwendet werden.
Durchsuchen Sie eine Liste aller Tags
