Branches

From OpenSimulator

(Difference between revisions)
Jump to: navigation, search
m (Robot: Cosmetic changes)
(Git Repos)
 
(30 intermediate revisions by 3 users not shown)
Line 2: Line 2:
 
{{Quicklinks}}
 
{{Quicklinks}}
  
This page outlines the various OpenSim repository branches, what they are for, and our policy for what goes into it.
+
== Branches and Tags in the Git Repo ==
 +
 
 +
OpenSimulator uses Git for its source code repository. The repository contains various branches and tags used to identify development branches and release branches of the code. The primary git repository is hosted on the opensimulator.org domain. A mirror is maintained on Github. The Github repo is sync'ed with the primary every 10 minutes.
 +
 
 +
=== Git Repos ===
 +
 
 +
* [http://opensimulator.org/viewgit/ '''Primary''' OpenSimulator Git Repo]
 +
* [https://github.com/opensim/ '''Mirror''' OpenSimulator Github Repo]
 +
* [https://bitbucket.org/opensimulator/opensim/src/master/ '''Mirror''' OpenSimulator Bitbucket Repo]
 +
* [https://bitbucket.org/opensimulator/libopenmetaverse/src/master/ libOpenMetaverse for OpenSimulator] - our fork of libOpenMetaverse
 +
 
 +
=== Repositories in the Primary Git ===
 +
 
 +
* [http://opensimulator.org/viewgit/?a=summary&p=opensim opensim] - the OpenSimulator source code
 +
* [http://opensimulator.org/viewgit/?a=tree&p=opensim-libs opensim-libs] - forks of third party libraries used in building OpenSimulator
 +
 
 +
This page outlines the repository branches and tags; what they are for, and our policy for what goes into it.
  
 
Also read
 
Also read
 
* [[Submitting code to OpenSim|Submitting Code to OpenSim]]
 
* [[Submitting code to OpenSim|Submitting Code to OpenSim]]
  
== master ==
+
== Branches ==
  
master holds bleeding edge OpenSim development.
+
=== master ===
  
=== OpenSim Policy ===
+
The master branch holds bleeding edge OpenSimulator development.
  
* Master is not guaranteed to function. It might be in the middle of a transition, or undergoing major overhaul.
+
'''OpenSimulator Master Branch Policies'''
* Master should always build (this is checked thru our CI builder)
+
 
* All tests should run green on trunk (this is also checked thru the CI builder at http://panda.opensimulator.org, though at the moment this spontaneously breaks quite often (needs fixing or wholesale replacement))
+
* 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
 
* Code should have been reasonably tested
  
== <version>-release ==
+
'''Browse the master branch'''
 +
 
 +
* [http://opensimulator.org/viewgit/?a=tree&p=opensim&h=refs/heads/master OpenSimulator master branch]
 +
 
 +
=== New major Releases ===
 +
 
 +
A new release is created for main master code.<br>
 +
* A tag with the full release version is added. (example 0.9.1.1).<br>
 +
* A Branch named as the release number is created.<br>
 +
* Master version is changed to at least the next minor number.<br>
 +
 
 +
=== New minor Releases ===
 +
 
 +
Minor releases will contain small changes or fixes to previous release.<br>
 +
In many cases master branch does correspond to the required release in this case it is just like a new release<br>
 +
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<br>
 +
except any special reason, they may have at most a TAG on it<br>
 +
 
 +
=== Old procedure ( prior to 0.9x) ===
 +
 
 +
Old procedure used extra names like '-Release' and '-postfixes' after the version name.<br>
 +
All releases should have their own version number.<br>
 +
Lower digits of a version name are clear and enough identification for minor changes and bug fixes<br>
 +
Something like  0.7.0.1-Release and 0.7.0.1-post-fixes was just redundant and confusing<br>
 +
Under new format this would be just 0.7.0.1 and 0.7.0.2<br>
 +
 
 +
=== 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'''
  
These branches contain release code. For instance, 0.7.0.2-release
+
* [http://opensimulator.org/viewgit/?a=summary&p=opensim List of Branches (see bottom of page)]
  
== <version>-post-fixes ==
+
== Tags ==
  
These branches contain release code that has had fixes applied afterwards. For instance, 0.7.0.1-post-fixes. If no post fix branch exists then no post fixes have been done.
+
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.
  
== other branches ==
+
'''Browse a list of all tags'''
  
Other branches mainly contain individual developer's work.
+
* [http://opensimulator.org/viewgit/?a=tags&p=opensim List of all tags]

Latest revision as of 08:34, 27 November 2023

[edit] Branches and Tags in the Git Repo

OpenSimulator uses Git for its source code repository. The repository contains various branches and tags used to identify development branches and release branches of the code. The primary git repository is hosted on the opensimulator.org domain. A mirror is maintained on Github. The Github repo is sync'ed with the primary every 10 minutes.

[edit] Git Repos

[edit] Repositories in the Primary Git

  • opensim - the OpenSimulator source code
  • opensim-libs - forks of third party libraries used in building OpenSimulator

This page outlines the repository branches and tags; what they are for, and our policy for what goes into it.

Also read

[edit] Branches

[edit] 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

[edit] 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.

[edit] 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

[edit] Release Candidates

Release candidates should be just snapshots of main code
except any special reason, they may have at most a TAG on it

[edit] 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

[edit] 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

[edit] 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

Personal tools
General
About This Wiki