Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Version control

...

IGB

...

git repo (main)

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. This branch is under active development and ultimately will become the next major release of IGB. 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

IGB branches and tags

IGB repository branches include:

  • Master branch - code under active development; developers issue pull requests to the master branch only
  • releaseCandidate branch - code to be packaged for release to users on BioViz.org; do not issue pull requests to this 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.  If you are developing an IGB App and want to write an App that is compatible with the currently released version of IGB, then 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 [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 release of IGB 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 changes to the API which are backwards compatible with all prior versions from the same major release. They also may contain new interfaces not present in the earlier versions. A new minor or bug fix release should always be compatible with IBG Apps built against earlier versions from the same major release.

New major releases of IGB 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 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.

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.

IGB release cycle - road map for 2016

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.

 

Info
If you're developing the core IGB code base, you should make changes to the master branch. For details, see Developing IGB.

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.The IGB project uses git for source code management. We use maven and Bitbucket pipelines to build and release IGB artifacts and user-friendly installers. 

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 (mvn) will obtain the latest copy of the genoviz compiled code (a "jar" file) and install it locally.

Maven 

The IGB project uses maven to build IGB, IGB Apps, and the GenoViz SDK. We provide access to new and old IGB-related jar files using the following maven repositories:

To include these in your project, see the top-level POM.xml file in the Integrated Genome Browser project code base.

History

The original GenoViz library - called "BioViews" - was first developed by Gregg Helt at UC Berkeley as part of his PhD research in the mid-1990s. Around then, Helt and two colleagues (Martin Reese and Cyrus Harmon) formed a bioinformatics software company called Neomorphic, which licensed the software from the University. With funding and development support from the Bioinformatics Department at Smith Kline Beecham, they continued to improve the library, renaming it the Neomorphic Genome Software Development Kit. Also during this period, Celera Genomics and the Institute for Genomic Research (TIGR) hired Neomorphic to build genome browser and annotation software. Ann Loraine joined the company in 1999 and helped build the Neomorphic Annotation Station for The Institute for Genomic Research. 

In October 2000, Affymetrix purchased Neomorphic and re-focused software effort on supporting and developing Affymetrix DNA microarray products. In 2001, Gregg Helt and colleagues began developing Integrated Genome Browser to visualize and analyze data from genome tiling arrays, which contained probes selected from (mostly) regular intervals along the genome. Visualization of probe intensity data alongside gene models was essential to developing algorithms to normalize and analyze the data, and the team at Affymetrix developed some of the first visual analytics algorithms in bioinformatics. Also, they developed some of the first indexed, random access file formats to enable partial loading of data sets that were too large to fit into computer memory. Support from Affymetrix along with federal grants to PIs Tom Gingeras and Gregg Helt funded early IGB development during this period. Affymetrix released IGB as part of their NetAffx Web site in the early 2000s.

In 2004, Affymetrix released IGB and NGSDK as open source software. This first release was done as a "tarball" on their Web site. In Jan. 2005, Affymetrix developers imported the tarball contents into a new CVS repository at Sourceforge and began using that for further development, discarding the internal repository at Affymetrix. In addition, they changed the name of the graphics library from "Neomorphic Genome Software Development Kit" to "Genoviz Software Development Kit". However, many of the graphics library's class names retain the prefix "Neo" - e.g., NeoWidget, NeoMap, etc.

In 2004, Ann Loraine joined the University of Alabama at Birmingham as an Assistant Professor, where she wrote funding proposals requesting further support for IGB and the Genoviz SDK. In 2008, she joined the College of Computing and Informatics at UNC Charlotte. Later that year, NSF awarded her a new grant to develop IGB and its companion data distribution site IGB Quickload. Developers at Affymetrix continued contributing to the code for several years after that. You can see their work by searching for commits from developers "chyekk" (Ed Erwin) and "gregghelt." 

After joining UNC Charlotte, Loraine and colleagues migrated the code to a subversion repository, also hosted at Sourceforge.  We continued to use this repository for many years. In 2014, we migrated the source code for IGB and the Genoviz SDK to a new git repository hosted at Atlassian's Bitbucket. 

Unfortunately, over the years the early development history pre-dating the 2004 open source release has been lost. In addition, early products built using Genoviz SDK are also lost. When the developers at Affymetrix prepared the first open source release, it seemed simpler and less risky to simply migrate the code directly into a new CVS repository and go from there. Now, of course, we are using tools that are more sophisticated than before, and we can easily trace how the code has changed dating from Jan 2005 until the present day.  If you have questions about what you see, feel free to get in touch.

Links