Code Quality and Code SecurityTopThe OpenVAS Source Code MapSource Code Branches for Stable and In-Development

Source Code Branches for Stable and In-Development

If you look at the OpenVAS source code for the first time, you might wonder what all those branches and tags are for and why most changes tend to occur in the "trunk" section.

Similar to many other projects, the OpenVAS project uses the concepts of branches and tags to signify important steps in the source code management. As you might have already noticed, almost all changes to the source code happen in the trunk section. The trunk is the place where bug fixes, new features and other additions appear first. 3

When a component has reached a stable state and the changes to this component have been evaluated by other developers, a decision is made to release a new version of this component. An intent to release a new version is usually announced on the developer mailing list. If the developers agree with this intent, a release is prepared. As part of the release process, the revision of the component that will become the release is tagged and appears in the tags section with the new version number, like openvas-client-release-1.1.0.

A tagged version is a snapshot of the source code as it was at the time of the release; this, among other things, allows users to use the source code management to check out older versions should this become necessary. No further development will occur on a tagged version. If changes to a tagged version are needed, these changes will occur in the trunk or the branch where this release originated from and will be released as a new release with a new tag.

As you have guessed from the last sentence, branches are different from tags in that further development can occur in a branch. The code is usually branched right before major changes are made that might render the trunk unstable for some time and cause incompatibilities with previous versions. One reason for branching is enabling these major changes to the codebase while still retaining a separate branch where minor maintenance changes to already released versions can occur.

For example, after releasing the 1.1.5 version of openvas-client, it might be decided that upcoming major changes justify a new branch. This leads to the creation of a branch name openvas-client-1-1. Future releases of the 1.1 series (1.1.6, 1.1.7) will come from this branch, while the trunk undergoes major changes that will ultimately lead to the release of 1.2.0.

If errors are found in the code which affect both the trunk and one or more branches, the are usually first fixed in the trunk and then propagated to the branches. This propagation is called "backporting" the fixes. Be aware that these backports make up the bulk of the changes to most branches. Only under very rare circumstances should it become necessary to propagate changes in the reverse direction, i.e. merge changes in the branch back into the trunk. Developers should avoid making changes to a branch that have not yet been incorporated into to the trunk unless there is a very good reason to do so.

Code Quality and Code SecurityTopThe OpenVAS Source Code MapSource Code Branches for Stable and In-Development