...
The IGB project uses git for version control. Previously, we used svn (subversion) and cvs. We migrated from an svn repository on SourceForge to a git repository on Bitbucket in 2014.
The main repository address is: https://bitbucket.org/lorainelab/integrated-genome-browser.
When you clone from this repository, by default you'll getthe master branch, the latest, most recent version of the code base. If you plan to develop IGB and would like your changes to be incorporated into the main repository and ultimately packaged for release to users, then you should issue pull requests to the master branch only.
To develop IGB, we use the Forking Workflow described in https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow
...
- Master branch - code under active development; developers issue pull requests to the master branch only
- currentRelease branch - branch corresponding to a released or or soon-to-be released version of IGB code to be packaged for release to users on BioViz.org; do not issue pull requests to the currentRelease branch.
When we package IGB for release on the BioViz.org Web site, we create a new tag. If you need to view the source code for older versions of IGB corresponding to specific versions released to users, check out the corresponding tag.
IGB versioning - major and minor releases
IGB version names use semantic versioning, described in Semantic Versioning 2.0.
IGB releases have version names like 8.3.0 or 8.4.2, following the naming convention [NM].[MN].[P], where M, N, M, and P are integers.
In IGB, N is the major release number, M is the minor release number, and P is the micro or "bug fix" release number. The IGB versioning system is important to understand if you are developing IGB Apps. (Bug fix releases are also called patches.)
All new versions of IGB will support all API methods available in earlier releases sharing the same major release number. New releases that increment the minor or micro numbers may contain additional methods and interfaces available for developers to use, but no existing methods will be removedchanges to the API which are backwards compatible with all prior versions from the same major release. In other words, a new minor or bug fix release should always be compatible with IBG Apps build against earlier versions from the same major release.
...