Changes to Our Public GitHub Infrastructure
For some weeks we have been busy working on major infrastructure changes to our public GitHub repositories at Greenbone · GitHub.
New Branching Scheme
Many communities using Git and GitHub have renamed their default branch name of their repositories from
main. Git and GitHub already switched to use
main for all new repositories. We decided to follow this path and changed the default branches of all our repositories to
Changing the default branch name let us think about about our branching strategy in general. In the past, we used long term branches with a name version scheme like
gvmd-9.0. The version could be different between components. For example,
gvm-libs-9.0 had to be used with
openvas-scanner-5.1. This created a lot of confusion as to which branch to use, even among our internal developers. Switching to a calendar based release versioning only slightly improved the situation.
So we took this as a chance to create a completely new branching scheme in conjunction with our ongoing efforts to strengthen our community. Our development branch will always be the
main branch. It will contain the code for the next release in the future. It is considered as unstable and should only be used by developers. We will not give any support for builds from
For repositories where we maintain several releases at the same time like
openvas-scanner, … we will have a
stable branch that contains code for the last and up-to-date released version. Users building from Git sources are encouraged to choose these branches. We will create bug-fix release from
stable branches regularly. Besides a
stable branch, there may be an additional
oldstable branch that contains code of the previous release. We will also create bug-fix releases from the
oldstable branch during its lifetime. As a consequence, this means we are going to maintain at most two releases for the community at the same time.
mainbranch is for future development.
stablebranch contains the up-to-date release and gets bug fixes regularly.
oldstablebranch contains the previous release and gets mostly security fixes.
Split of GSA and gsad
GSA can now be build with
yarn && yarn build
Afterwards, the created files in the
build directory must be copied to a specific directory to be provided by
cp -r build/* $INSTALL_PREFIX/share/gvm/gsad/web/
/usr/local by default and should be
/usr for Linux distributions like Kali Linux. The
$INSTALL_PREFIX can be set via CMake
-DCMAKE_INSTALL_PREFIX while building