The IGB project uses git for version control. Previously, we used svn (subversion) and cvs before that. 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 get the master branch, the latest, most recent version of the code base. This branch is under active development and ultimately will become the next major release of IGB. If you develop IGB, 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
IGB uses 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 [M].[N].[P], where M, N, 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. (Bug fix releases are also called patches.)
All new minor and bug fix releases of IGB support all API methods supported in earlier versions with the same major release number. New releases that increment the minor or micro numbers may contain changes to the API, but these will maintain backwards-compatibility with all prior versions from the same major release. This means that new minor or bug fix releases can run any IGB App built against earlier versions from the same major release.
New major releases of IGB will contain so-called "contract breaking" changes to the IGB API. This means that a new release that increments the major number (e.g., releasing IGB N.0.0) may include changes to the API methods that affect IGB Apps built using the previous major release.
To ensure that 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. 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.
Before making a major release, the IGB core development team contacts everyone we know of who is developing IGB Apps to alert them to upcoming changes in the API.
| If you're developing the core IGB code base, you should make changes to the master branch. For details, see Developing IGB. |
The IGB core development team plans to release a new set of IGB service APIs for App developers in the first part of 2016 as part of the next major release of IGB, which will be IGB 9.0.0.
In the meantime, the team will continue making minor, mostly "bug fix" releases of IGB 8.5 and above.
All code released as part of IGB 8.5 will continue to support App APIs currently in place, but the IGB 9 release will include heavy refactoring of the API.
Development of IGB 9 will happen on the master branch. As soon as the master branch no longer supports existing APIs, we'll increment the version number in the repository to signal that we're now developing IGB 9. We may also make a new branch for IGB 8 to facilitate continued bug fix and minor releases developed for IGB 8.
Development of IGB versions being prepared for release to users will occur on the releaseCandidate branch, and we will tag each released version using the convention igb-M.N.P.
The following git repository contains broken QuickLoad sites that are helpful for testing within IGB.
https://bitbucket.org/lorainelab/brokenquickloads
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.
For information about the GenoPub project, please contact David Nix, Huntsman Cancer Institute.