Branches

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

Also read

• Submitting Code to OpenSim

/trunk

The term 'trunk' refers to the trunk of a tree, the 'root branch' of the repository.

It is intended to hold the bleeding-edge development.

OpenSim Policy

• Trunk is not guaranteed to function. It might be in the middle of a transition, or undergoing major overhaul.
• Trunk 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)
• Code should have been reasonably tested

/tags/#major.#minor.#sub-stable

The term 'tag' refers to labeling a certain revision with some information.

In OpenSim The label 'stable' merely needs 'a little less unstable than the rest' and the revision is often tagged some time after it was committed, when people have been using it for a while and seen it working.

This should only be used as an recommendation and in no way implies any extra stability or feature-richness.

An example would be the /tags/0.6.0-stable tag.

OpenSim Policy

• We should strive to up the #sub at least once a month, to keep it useable and as a viable point of recommendation.
• Revisions that are candidates for 'stable' tags should have been tested for at least a week.
• Any interface breaking changes between version numbers should be documented.
• Tools to aid in the transition from one version number to another should be supplied.

/branches/#major.#minor.#sub-post-fixes

The term 'branch' refers to a code path 'forking' off the 'trunk' - code changes that start from a certain revision, and then diverge from that. The act of bringing the changes in a branch back into trunk is called 'merging'.

The 'post-fixes' branch is copied from the corresponding 'stable' tag, and then selected revisions are merged into it from trunk. Ideally, it should be the most stable and secure revision of that particular OpenSim version.

OpenSim Policy

The branch post-fixes should only include code changes that

• Addresses drm and security issues
• Cleanly furthers stability and performance. With 'cleanly' is meant that the changes are local enough and simple enough that they show little risk of introducing new security or stability bugs.
• Cleanly adds debugging and/or reporting features to help further work with stability and security on the post-fixes branch.