This page contains our policies for managing code branching and other CM practices.
You can access our code on SVN repository:
The code on trunk represents the latest state of our work. We want to keep the code on trunk as stable as possible.
From the last conversation we had on cross-dev list, we will cut the overhead of working on branches and we'll work on the trunk code.
The code on branches are still under development, and may not be stable enough to compile and use. If you are going to use this code, be aware of this. :)
We usually make branches using the format bug_<bug_number>, under the branches folder, as expected.
Also, we are adopting some special branches, for special cases:
- New release: for example, we have the "1.1" branch with code for the 1.1 release.
- Service/Maintenance release: for example, we have the "3.6_SR" branch, created just after Helios was launched, that will contain any fixes/improvements that will be released on SR1 or SR2.
- Any other case that may apply...
We still have some old branches that don't follow this standard, but from now on this naming policy should be used whenever applicable.
Since the tag on SVN is just an easier way to refer to an specific revision, we can use it whenever we want to mark an special point during development, or more commonly, milestones (for instance, we have "1.1" and "3.6_RC5" tags).
Also from the conversation on cross-dev list, we'll use tags to mark stable revisions, and we'll later use this tag on our build process, so we'll always build from stable code.