Branches/de
From OpenSimulator
 |
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
The master branch holds bleeding edge OpenSimulator development.
OpenSimulator Master Branch Policies
- 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
Browse the master branch
New major Releases
A new release is created for main master code.
- A tag with the full release version is added. (example 0.9.1.1).
- A Branch named as the release number is created.
- Master version is changed to at least the next minor number.
New minor Releases
Minor releases will contain small changes or fixes to previous release.
In many cases master branch does correspond to the required release in this case it is just like a new release
On occasions it may be required to only include selected commits or even unique special code, in this case:
- change (checkout) to the branch of release to be fixed (or tag on main)
- Increment its minor version number(s).
- Create a new branch named as that version.
- do the fixes
- release
Release Candidates
Release candidates should be just snapshots of main code
except any special reason, they may have at most a TAG on it
Old procedure ( prior to 0.9x)
Old procedure used extra names like '-Release' and '-postfixes' after the version name.
All releases should have their own version number.
Lower digits of a version name are clear and enough identification for minor changes and bug fixes
Something like 0.7.0.1-Release and 0.7.0.1-post-fixes was just redundant and confusing
Under new format this would be just 0.7.0.1 and 0.7.0.2
Other Branches
Other branches mainly contain temporary development work, for example to develop new code without disturb current master
Browse a list of all branches
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
