Branches/de
From OpenSimulator
(→Branches and Tags in the Git Repo) |
(→Branches) |
||
| Line 27: | Line 27: | ||
=== master === | === master === | ||
| − | + | Der Master-Zweig verfügt über die neueste OpenSimulator-Entwicklung. | |
| − | '''OpenSimulator Master Branch | + | '''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 is not guaranteed to function. It might be in the middle of a transition, or undergoing a major overhaul. | ||
| Line 36: | Line 36: | ||
* Code should have been reasonably tested | * 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''' | ||
* [http://opensimulator.org/viewgit/?a=tree&p=opensim&h=refs/heads/master OpenSimulator master branch] | * [http://opensimulator.org/viewgit/?a=tree&p=opensim&h=refs/heads/master OpenSimulator master branch] | ||
| − | === | + | === Neue Hauptveröffentlichungen === |
| − | + | Für den Hauptmastercode wird ein neues Release erstellt.<br> | |
| − | * | + | * Ein Tag mit der Vollversion wird hinzugefügt. (Beispiel 0.9.1.1). |
| − | * | + | * Es wird ein Branch mit dem Namen der Release-Nummer erstellt. |
| − | * Master | + | * Die Master-Version wird mindestens auf die nächste Minor-Nummer geändert. |
| − | |||
| − | + | === Neue Nebenveröffentlichungen === | |
| − | In | + | |
| − | + | Nebenversionen enthalten kleine Änderungen oder Korrekturen gegenüber der vorherigen Version.<br> | |
| − | * | + | In vielen Fällen entspricht der Master-Zweig der erforderlichen Version. In diesem Fall handelt es sich lediglich um eine neue Version.<br> |
| − | * | + | 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 | * 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.<br> | |
| − | + | Alle Veröffentlichungen sollten eine eigene Versionsnummer haben.<br> | |
| − | + | Die unteren Ziffern eines Versionsnamens sind klar und bieten eine ausreichende Identifizierung für kleinere Änderungen und Fehlerbehebungen.<br> | |
| − | + | So etwas wie 0.7.0.1-Release und 0.7.0.1-Post-Fixes war einfach überflüssig und verwirrend.<br> | |
| − | + | Im neuen Format wären dies nur 0.7.0.1 und 0.7. 0,2<br> | |
=== Other Branches === | === 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''' |
| − | * [http://opensimulator.org/viewgit/?a=summary&p=opensim List of Branches ( | + | * [http://opensimulator.org/viewgit/?a=summary&p=opensim List of Branches (siehe unten auf der Seite)] |
== Tags == | == Tags == | ||
Revision as of 01:11, 2 December 2023
 |
Languages: |
|
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
Tags were originally used to trigger the automatic release build process. When it was time for a release, a <version>-release tag was applied to a branch, triggering the automated process that produced the release tarballs. For more details see Automated Release Building. Tags continue to be used to mark releases but may also be used for other purposes.
Browse a list of all tags
