Version control
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 repository address is: https://bitbucket.org/lorainelab/integrated-genome-browser.
When you clone from this repository, by default you'll get the master branch, the latest, most recent version of the code base.
To develop IGB, we use the Forking Workflow described in https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow
IGB branches and tags
IGB repository branches include:
- Master branch - code under active development
- currentRelease branch - branch corresponding to a released or or soon-to-be released version of IGB on BioViz.org
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 releases have version names like 8.3.0 or 8.4.2, following the naming convention [N].[M].[P], where 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. All new versions of IGB will support all API methods available in earlier releases sharing the same major release number. New releases may contain additional methods and interfaces available for developers to use, but no existing methods will be removed. 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.
If we increment the major release number, that means many aspects of the API are likely to have changed. This means that any new release that increments the major number (e.g., releasing IGB N.0.0) may include incompatible changes to API methods. To ensure that your users can run your App when a new major version is released, you should re-build your App using the latest IGB platform and release it in the usual way. We recommend you release versions of your App that are compatible with all major releases above IGB 8.0.0 to ensure that the greatest number of users can run your App.
However, if you are unable to release an update to your App, users will always be able to run it using older versions of IGB, which they can get from our files download page at Sourceforge.
If you are unable to do this, users will still be able to run your App, but they'll need to install the previous version of IGB. This is not difficult to do as older IGB installers are available from Sourceforge.
Before making a major release, the IGB core development team contacts everyone we know of who is developing IGB Apps to alert them to the upcoming change.
IGB code base
The IGB repository is organized into sub-projects, including:
- genometry - genomic data models used in IGB and the DAS server code
- igb - the core IGB application
- plugins - functions added via plug-in interface, plug-ins are also called bundles (uses OSGi)
- common - common classes used by the other projects
QuickLoad testing
The following git repository contains broken QuickLoad sites that are helpful for testing within IGB.
https://bitbucket.org/lorainelab/brokenquickloads
Genoviz SDK
IGB depends on the Genoviz Software Development Kit (Genoviz SDK) which is version-controlled in a separate repository at https://bitbucket.org/lorainelab/genoviz-sdk. When you build IGB, the compilation tool we use (maven) will obtain the latest copy of the genoviz compiled code (a "jar" file) and install it locally.
GenoPub project
For information about the GenoPub project, please contact David Nix, Huntsman Cancer Institute.